Processo de projeto de engenharia VRC

O processo de projeto de engenharia é uma série de etapas que os engenheiros seguem quando tentam resolver um problema e projetar uma solução para algo; é uma abordagem metódica para a resolução de problemas. Não existe um processo de design único universalmente aceito, e a maioria dos engenheiros tem sua própria abordagem sobre como o processo funciona. O processo geralmente começa com um problema e termina com uma solução, mas as etapas intermediárias podem variar.

Uma característica comum da maioria dos processos de design é que eles são iterativos e os designers podem ter que voltar às etapas anteriores do processo e/ou repetir todo o processo indefinidamente até chegarem a uma solução minimamente viável.

O processo de projeto de engenharia descrito neste artigo não é a única versão correta do processo, é apenas um exemplo. Deve fornecer um bom ponto de partida para os alunos explorarem o processo de engenharia.

Um processo de design muito simples pode incluir apenas três etapas, conforme mostrado abaixo: Definir, desenvolver soluções e otimizar (esta ilustração está disponível como pôster em tamanho real em posters.vex.com se você quiser um para sua sala de aula!).

Processo_de_design_básico.png

Outro exemplo de processo de design é Project Lead The Way's Gateway Design Process.

Etapas do processo de projeto de engenharia

Para este artigo, consideraremos um processo de design que corresponda ao que os Juízes procuram ao entrevistar equipes e revisar seus cadernos de engenharia nas competições da REC Foundation.

Identifique o Desafio & Estabeleça Metas

Isso às vezes é chamado de “Perguntar” ou “Definir”. Identificar o desafio deve ser sempre a primeira etapa abordada no processo de design. 

Para a primeira iteração do processo de design, o caderno da equipe deve incluir uma breve descrição do desafio geral do jogo e dividi-lo em desafios menores que devem ser alcançados para o sucesso. A melhor prática é listar perguntas que precisam ser respondidas por meio de pesquisas ou testes, por exemplo:

  • Qual é a estratégia mais eficaz para jogar?
  • Quais são as formas de marcar pontos?
  • Quão rápido o robô precisa se mover?
  • Como o robô pode pegar os objetos de pontuação?
  • Quantos objetos de pontuação o robô precisa segurar?

Através deste processo, as equipes devem criar uma lista de recursos que podem querer em seu robô e listas de requisitos e restrições do jogo. Por exemplo, se um desafio exige que um robô empilhe objetos o mais alto possível, a equipe pode decidir que quer que seu robô seja alto. No entanto, o manual do jogo pode ter uma restrição sobre a altura do robô em um determinado momento. Todos estes critérios devem ser explorados e compreendidos antes de passar para a fase de brainstorming.

Para ciclos posteriores do processo de design, esta etapa pode ser identificar algo no robô que não está funcionando tão bem quanto o esperado ou necessário e descrever o que uma boa solução incluiria. Por exemplo, um desafio pode ser "O braço do robô precisa ser capaz de chegar mais alto para marcar a bola", e uma meta para cumprir o desafio pode ser "A parte inferior da garra deve ser capaz de alcançar até 16 "ao segurar uma bola." As restrições para este desafio podem se sobrepor a restrições maiores do jogo, por exemplo, tamanho e limites de expansão vertical.

Diagrama de Brainstorm &

Um bom brainstorming começa com uma compreensão partilhada do problema, incluindo todos os requisitos e restrições. Sem compreender o problema, pode-se perder tempo com ideias irrelevantes que não satisfazem o problema básico em questão. Durante o brainstorming, também é importante evitar julgar as ideiasdos. Isso pode sufocar o processo criativo e desencorajar a participação dos membros da equipe.

Se ficar claro que os membros da equipe não entendem completamente o problema, a equipe deverá recomeçar na primeira etapa do processo (ou seja, “Identificar o problema” ou “Perguntar”).

Durante o brainstorming, os alunos também podem querer investigar desafios do mundo real que sejam semelhantes aos apresentados pelo jogo. Eles também podem verificar se alguma outra competição de robótica utilizou desafios semelhantes no passado. O brainstorming inclui a coleta de dados de outras fontes para ajudar os alunos a criar uma solução bem-sucedida.

Soluções promissoras devem ser documentadas no caderno da equipe, incluindo desenhos ou imagens rotuladas. Se a equipe obtiver ideias de outras fontes, essas fontes deverão ser claramente identificadas no caderno.

Escolha uma solução & Faça um plano

Uma vez concluído o brainstorming e geradas várias ideias, as equipes devem avaliar objetivamente cada ideia. O objetivo é encontrar a melhor solução para a equipe, independente da origem. Uma tabela pode ajudar as equipes a considerar e comparar os méritos de cada ideia em relação a desejos e restrições específicas de design. No exemplo abaixo, cada critério é avaliado numa escala de 0 a 5 pontos, onde 0 não atende e 5 supera as expectativas. Como a “Ideia 4” tem a pontuação geral mais alta, seria a escolha objetiva.

Ideia

Critério 1

Critério 2

Critério 3

Critério 4

Pontuação total

Ideia 1

3

3

2

1

9

Ideia 2

5

5

0

0

10

Ideia 3

1

1

5

5

12

Ideia 4

4

4

4

4

16

A equipe deve documentar esse processo no caderno e explicar como e por que escolheu sua solução. Eles também devem descrever completamente a solução em seu caderno de engenharia, incluindo um plano de como irão construí-la. Para equipes avançadas, este plano pode incluir a criação de modelos CAD ou desenhos detalhados de montagem.

Programa Construir &

É aqui que as equipes passarão a maior parte do tempo e quando os protótipos e os robôs e programas finais serão criados. As compilações — tanto para código quanto para robôs — geralmente começam como projetos básicos e evoluem à medida que detalhes são adicionados em ciclos posteriores do processo de design. Os alunos devem fazer anotações detalhadas em seus cadernos enquanto constroem a programação & , registrando o que veem, tentando descobrir por que algumas coisas funcionam melhor que outras e, em seguida, criando protótipos ou programas adicionais para testar novas ideias. Coletar dados e registrá-los no caderno é uma parte importante da construção e da programação.

Teste a solução

Durante esta etapa, os alunos testarão o que construíram ou programaram para ver o que funciona, o que não funciona e o que pode ser melhorado. Os procedimentos de teste devem ser bem documentados no caderno e incluir todos os resultados mensuráveis. O principal objetivo desta etapa é decidir se a construção ou código atende ao desafio e tem o desempenho esperado e necessário.

Repita o processo de design

O que acontece quando algo não funciona nos testes? Os alunos analisam o problema para identificar o novo desafio que ele apresenta e iniciam um novo ciclo do processo de design!

Nem todos os ciclos do processo de design precisarão de todas as etapas, e alguns podem pular de uma etapa para outra ou repetir uma etapa várias vezes antes de passar para a próxima. As equipes de design não devem ter medo de retroceder no processo de design. O objetivo final é criar o melhor design possível, melhorando-o continuamente. Os ciclos de design provavelmente também se sobreporão, especialmente entre os subsistemas do robô e o código. As equipes devem fazer o possível para identificar em quais etapas do processo de design estão trabalhando à medida que fazem anotações no caderno.

Então, como uma equipe decide quando seu robô termina?  Simples: a equipe precisa definir um cronograma e cumpri-lo. Este cronograma irá variar muito de equipe para equipe, dependendo das circunstâncias. Se uma equipe tiver seis semanas para projetar e construir seu robô antes da primeira competição, ela deverá elaborar algum tipo de cronograma para esse período. Algumas equipes planejarão cada etapa do processo de construção, enquanto outras farão apenas uma rápida visão geral.

O cronograma nem sempre é imutável; em última análise, as únicas datas fixas são a data de início do projeto e o prazo de conclusão do robô (geralmente a data de uma competição). É provável que todo o resto mude à medida que o processo se desenrola.