Процесс инженерного проектирования VRC

Процесс инженерного проектирования — это серия шагов, которым следуют инженеры, когда пытаются решить проблему и разработать решение для чего-либо; это методический подход к решению проблем. Не существует единого общепринятого процесса проектирования, и у большинства инженеров есть свои представления о том, как этот процесс работает. Обычно процесс начинается с проблемы и заканчивается решением, но промежуточные этапы могут различаться.

Одной из общих характеристик большинства процессов проектирования является то, что они являются итеративными, и дизайнерам, возможно, придется возвращаться к предыдущим шагам процесса и/или повторять весь процесс снова и снова, пока не достигнут минимально жизнеспособного решения.

Процесс инженерного проектирования, описанный в этой статье, не является единственной правильной версией процесса, это всего лишь один пример. Он должен стать хорошей отправной точкой для изучения студентами инженерного процесса.

Очень простой процесс проектирования может включать всего 3 шага, как показано ниже: определение, разработка решений и оптимизация (эта иллюстрация доступна в виде полноразмерного плаката на сайте , если вы хотите такой для своего класса!).

Другой пример процесса проектирования — Руководитель проекта «Процесс проектирования шлюза The Way.

Этапы процесса инженерного проектирования

В этой статье мы рассмотрим процесс проектирования, который соответствует тому, на что обращают внимание судьи, проводя собеседования с командами и просматривая их инженерные тетради на соревнованиях REC Foundation.

Определите задачу & Установите цели

Иногда это называют «Спросить» или «Определить». Выявление проблемы всегда должно быть первым шагом, который решается в процессе проектирования. 

Для первой итерации процесса проектирования блокнот команды должен включать очень краткое описание общей задачи игры и разбить ее на более мелкие задачи, которые необходимо решить для успеха. Лучшей практикой является составление списка вопросов, на которые необходимо ответить посредством исследования или тестирования, например:

• Какая стратегия игры наиболее эффективная?
• Какие есть способы набрать очки?
• Как быстро должен двигаться робот?
• Как робот может подобрать засчитываемые объекты?
• Сколько объектов для подсчета очков должен удерживать робот?

В ходе этого процесса команды должны составить список функций, которые они могут захотеть иметь в своем роботе, а также списки требований и ограничений игры. Например, если задача требует, чтобы робот складывал предметы как можно выше, команда может решить, что их робот должен быть высоким. Однако в руководстве к игре могут быть ограничения на высоту робота в любой момент времени. Все эти критерии следует изучить и понять, прежде чем переходить к фазе мозгового штурма.

На более поздних циклах процесса проектирования этим шагом может быть определение того, что в роботе работает не так, как ожидалось или необходимо, и описание того, что будет включать в себя хорошее решение. Например, задача может заключаться в следующем: «Рука робота должна иметь возможность подниматься выше, чтобы забить мяч», а цель выполнения задачи может заключаться в следующем: «Нижняя часть клешни должна быть в состоянии дотянуться до 16 «когда держишь мяч». Ограничения для этой задачи могут перекрывать более крупные ограничения из игры, например ограничения по размеру и вертикальному расширению.

Мозговой штурм & Диаграмма

Хороший мозговой штурм начинается с общего понимания проблемы, включая все требования и ограничения. Без понимания проблемы время может быть потрачено впустую на бесполезные идеи, которые не решают основную проблему. Во время мозгового штурма также важноидей друг друга. Это может задушить творческий процесс и отбить охоту у членов команды участвовать в нем.

Если становится ясно, что члены команды не до конца понимают проблему, команде следует начать заново с первого этапа процесса (т. е. «Определить проблему» или «Спросить»).

Во время мозгового штурма учащиеся также могут захотеть исследовать проблемы из реального мира, аналогичные тем, которые возникают в игре. Они также могут посмотреть, использовались ли в прошлом какие-либо другие соревнования по робототехнике с похожими задачами. Мозговой штурм включает сбор данных из других источников, чтобы помочь учащимся найти успешное решение.

Перспективные решения должны быть задокументированы в блокноте команды, включая помеченные рисунки или изображения. Если команда получает идеи из других источников, эти источники должны быть четко указаны в блокноте.

Выберите решение & Составьте план

После завершения мозгового штурма и генерации нескольких идей команды должны объективно оценить каждую идею. Цель — найти лучшее решение для команды, независимо от источника. Таблица может помочь командам рассмотреть и сравнить достоинства каждой идеи с учетом конкретных дизайнерских пожеланий и ограничений. В приведенном ниже примере каждый критерий оценивается по шкале от 0 до 5 баллов, где 0 не соответствует ожиданиям, а 5 превышает ожидания. Поскольку «Идея 4» имеет наивысший общий балл, она будет объективным выбором.

Команда должна задокументировать этот процесс в блокноте и объяснить, как и почему они выбирают свое решение. Им также следует полностью описать решение в своей инженерной тетради, включая план его создания. Для продвинутых команд этот план может включать создание моделей САПР или подробных сборочных чертежей.

Программа сборки &

Именно здесь команды будут проводить большую часть своего времени, когда создаются прототипы и финальные версии роботов и программ. Сборки — как для кода, так и для роботов — обычно начинаются с базового проекта и развиваются по мере добавления деталей на более поздних циклах процесса проектирования. Студенты должны делать подробные записи в своей тетради во время создания & программирования, записывать то, что они видят, пытаясь выяснить, почему некоторые вещи работают лучше, чем другие, а затем создавать дополнительные прототипы или программы для проверки новых идей. Сбор данных и запись их в блокнот — важная часть сборки и программирования.

Проверьте решение

На этом этапе учащиеся проверят то, что они создали или запрограммировали, чтобы увидеть, что работает, что нет и что можно улучшить. Процедуры тестирования должны быть хорошо задокументированы в журнале и включать все измеримые результаты. Основная цель этого шага — решить, соответствует ли сборка или код поставленной задаче и работает ли так, как ожидалось и необходимо.

Повторите процесс проектирования

Что происходит, когда что-то не работает при тестировании? Студенты анализируют проблему, чтобы определить новую задачу, которую она представляет, и начинают новый цикл процесса проектирования!

Не во всех циклах процесса проектирования потребуются все этапы, а некоторые могут переходить от шага к шагу или повторять шаг несколько раз, прежде чем перейти к следующему. Команды дизайнеров не должны бояться идти назад в процессе проектирования. Конечная цель — создать наилучший возможный дизайн, улучшая его снова и снова. Циклы проектирования, вероятно, также будут перекрываться, особенно между подсистемами роботов и кодом. Команды должны приложить все усилия, чтобы определить, над какими этапами процесса проектирования они работают, делая записи в блокноте.

Так как же команда решает, когда их робот будет готов?  Все просто: команде нужно установить график и затем придерживаться его. Этот график будет сильно различаться от команды к команде в зависимости от обстоятельств. Если у команды есть шесть недель на проектирование и сборку робота перед первым соревнованием, ей следует составить какой-то график на этот период времени. Некоторые команды планируют каждый шаг процесса сборки, а другие просто делают краткий обзор.

График не всегда высечен в камне; в конечном итоге единственными фиксированными датами являются дата начала проекта и крайний срок завершения робота (обычно дата конкурса). Все остальное, вероятно, изменится по мере развития процесса.