Proceso de diseño de ingeniería VRC

El proceso de diseño de ingeniería es una serie de pasos que siguen los ingenieros cuando intentan resolver un problema y diseñar una solución para algo; es un enfoque metódico para la resolución de problemas. No existe un proceso de diseño único universalmente aceptado y la mayoría de los ingenieros tienen su propia interpretación de cómo funciona el proceso. El proceso generalmente comienza con un problema y termina con una solución, pero los pasos intermedios pueden variar.

Una característica común de la mayoría de los procesos de diseño es que son iterativos y es posible que los diseñadores tengan que volver a pasos anteriores del proceso y/o repetir todo el proceso una y otra vez hasta llegar a una solución mínimamente viable.

El proceso de diseño de ingeniería descrito en este artículo no es la única versión correcta del proceso, es sólo un ejemplo. Debería proporcionar un buen punto de partida para que los estudiantes exploren el proceso de ingeniería.

Un proceso de diseño muy simple puede incluir solo 3 pasos como se muestra a continuación: Definir, Desarrollar Soluciones y Optimizar (esta ilustración está disponible como un póster de tamaño completo en posters.vex.com si desea uno para su salón de clases).

Otro ejemplo de proceso de diseño es Project Lead The Way's Gateway Design Process.

Pasos del proceso de diseño de ingeniería

Para este artículo, consideraremos un proceso de diseño que coincide con lo que buscan los jueces cuando entrevistan a los equipos y revisan sus cuadernos de ingeniería en las competencias de la Fundación REC.

Identificar el Reto & Establecer Metas

A esto a veces se le llama "Preguntar" o "Definir". Identificar el desafío siempre debe ser el primer paso que se aborda en el proceso de diseño. 

Para la primera iteración del proceso de diseño, el cuaderno del equipo debe incluir una descripción muy breve del desafío general del juego y dividirlo en desafíos más pequeños que deben lograrse para tener éxito. La mejor práctica es enumerar las preguntas que deben responderse mediante investigaciones o pruebas, por ejemplo:

• ¿Cuál es la estrategia más eficaz para jugar?
• ¿Cuáles son las formas de sumar puntos?
• ¿A qué velocidad debe moverse el robot?
• ¿Cómo puede el robot recoger los objetos puntuables?
• ¿Cuántos objetos puntuables debe sostener el robot?

A través de este proceso, los equipos deben elaborar una lista de características que podrían desear en su robot y listas de requisitos y limitaciones del juego. Por ejemplo, si un desafío requiere que un robot apile objetos lo más alto posible, el equipo podría decidir que quiere que su robot sea alto. Sin embargo, el manual del juego puede tener una restricción sobre la altura que puede tener el robot en un momento dado. Todos estos criterios deben explorarse y comprenderse antes de pasar a la fase de lluvia de ideas.

Para ciclos posteriores del proceso de diseño, este paso podría consistir en identificar algo en el robot que no funciona tan bien como se esperaba o necesitaba y describir qué incluiría una buena solución. Por ejemplo, un desafío podría ser "El brazo robótico debe poder llegar más alto para anotar el balón" y un objetivo para lograr el desafío podría ser "La parte inferior de la garra debe poder alcanzar hasta 16 puntos". "al sostener una pelota." Las restricciones de este desafío pueden superponerse a restricciones más grandes del juego, por ejemplo, límites de tamaño y expansión vertical.

Lluvia de ideas & Diagrama

Una buena lluvia de ideas comienza con una comprensión compartida del problema, incluidos todos los requisitos y limitaciones. Sin comprender el problema, se puede perder el tiempo en ideas irrelevantes que no satisfacen el problema básico en cuestión. Durante la lluvia de ideas, tambiénimportante evitarlas ideas de los demás. Esto puede sofocar el proceso creativo y disuadir a los miembros del equipo de participar.

Si queda claro que los miembros del equipo no comprenden completamente el problema, el equipo debe comenzar de nuevo desde el primer paso del proceso (es decir, “Identificar el problema” o “Preguntar”).

Durante la lluvia de ideas, es posible que los estudiantes también quieran investigar desafíos del mundo real que sean similares al que plantea el juego. También pueden ver si otras competiciones de robótica han utilizado desafíos similares en el pasado. La lluvia de ideas incluye la recopilación de datos de otras fuentes para ayudar a los estudiantes a crear una solución exitosa.

Las soluciones prometedoras deben documentarse en el cuaderno del equipo, incluidos dibujos o fotografías etiquetados. Si el equipo obtiene ideas de otras fuentes, esas fuentes deben identificarse claramente en el cuaderno.

Elija una solución & Haga un plan

Una vez que se ha completado la lluvia de ideas y se han generado varias ideas, los equipos deben evaluar objetivamente cada idea. El objetivo es encontrar la mejor solución para el equipo, independientemente de la fuente. Una tabla podría ayudar a los equipos a considerar y comparar los méritos de cada idea en relación con deseos y limitaciones de diseño específicos. En el siguiente ejemplo, cada criterio se evalúa en una escala de 0 a 5 puntos, donde 0 no cumple y 5 supera las expectativas. Dado que la “Idea 4” tiene la puntuación general más alta, sería la elección objetiva.

El equipo debe documentar este proceso en el cuaderno y explicar cómo y por qué eligen su solución. También deben describir completamente la solución en su cuaderno de ingeniería, incluido un plan sobre cómo la construirán. Para equipos avanzados, este plan puede incluir la creación de modelos CAD o dibujos de ensamblaje detallados.

Programa Construir &

Aquí es donde los equipos pasarán la mayor parte de su tiempo y cuando se crean los prototipos y los robots y programas finales. Las compilaciones, tanto para código como para robots, generalmente comienzan como diseños básicos y evolucionan a medida que se agregan detalles en ciclos posteriores del proceso de diseño. Los estudiantes deben tomar notas detalladas en su cuaderno mientras crean programación & , registrando lo que ven, tratando de descubrir por qué algunas cosas funcionan mejor que otras y luego creando prototipos o programas adicionales para probar nuevas ideas. Recopilar datos y registrarlos en el cuaderno es una parte importante de la construcción y la programación.

Pruebe la solución

Durante este paso, los estudiantes probarán lo que han creado o programado para ver qué funciona, qué no y qué se puede mejorar. Los procedimientos de prueba deben estar bien documentados en un cuaderno y deben incluir todos los resultados mensurables. El objetivo principal de este paso es decidir si la compilación o el código cumple con el desafío y funciona según lo esperado y necesario.

Repita el proceso de diseño

¿Qué sucede cuando algo no funciona en las pruebas? ¡Los estudiantes analizan el problema para identificar el nuevo desafío que presenta y comienzan un nuevo ciclo del proceso de diseño!

No todos los ciclos del proceso de diseño necesitarán todos los pasos, y algunos pueden saltar de un paso a otro o repetir un paso varias veces antes de pasar al siguiente. Los equipos de diseño no deberían tener miedo de retroceder en el proceso de diseño. El objetivo final es crear el mejor diseño posible mejorándolo una y otra vez. Los ciclos de diseño probablemente también se superpondrán, especialmente entre los subsistemas de robots y el código. Los equipos deben hacer todo lo posible para identificar en qué paso(s) del proceso de diseño están trabajando mientras realizan entradas en el cuaderno.

Entonces, ¿cómo decide un equipo cuándo termina su robot?  Simple: el equipo necesita establecer un cronograma y luego cumplirlo. Este calendario variará mucho de un equipo a otro dependiendo de sus circunstancias. Si un equipo tiene seis semanas para diseñar y construir su robot antes de la primera competición, debería elaborar algún tipo de cronograma para este período de tiempo. Algunos equipos planificarán todos y cada uno de los pasos de su proceso de construcción, mientras que otros simplemente harán una descripción general rápida.

El calendario no siempre está escrito en piedra; En última instancia, las únicas fechas fijas son la fecha de inicio del proyecto y la fecha límite de finalización del robot (normalmente la fecha de una competición). Es probable que todo lo demás cambie a medida que se desarrolle el proceso.