VRCエンジニアリング設計プロセス – V5RC

エンジニアリング設計プロセスは、エンジニアが問題を解決し、何かに対するソリューションを設計しようとするときに従う一連のステップです。それは問題解決に対する系統的なアプローチです。広く受け入れられている単一の設計プロセスはなく、ほとんどのエンジニアはプロセスの仕組みについて独自の工夫をしています。通常、プロセスは問題で始まり、解決策で終わりますが、中間のステップは異なる場合があります。

ほとんどの設計プロセスに共通する特徴の 1 つは、プロセスが反復的であり、設計者は、最小限の実行可能な解決策に到達するまで、プロセスの前のステップに戻ったり、プロセス全体を何度も繰り返したりする必要がある場合があります。

この記事で概説したエンジニアリング設計プロセスは、プロセスの唯一の正しいバージョンではなく、単なる一例にすぎません。学生がエンジニアリングプロセスを探索するための良い出発点となるはずです。

非常に単純なデザインプロセスには、以下に示すように、定義、ソリューションの開発、最適化の 3 つのステップのみが含まれます (このイラストは、教室で使用したい場合は、でフルサイズのポスターとして入手できます!)。

基本設計プロセス.png

別の設計プロセスの例は、プロジェクトリード The Way のゲートウェイ設計プロセスです。

エンジニアリング設計プロセスのステップ

この記事では、REC Foundation のコンテストでチームにインタビューし、エンジニアリングノートをレビューする際に審査員が何を求めているかに一致する設計プロセスを検討します。

課題を特定する & 目標を設定する

これは、「質問する」または「定義する」と呼ばれることもあります。課題を特定することは、常に設計プロセスで取り組む最初のステップである必要があります。

設計プロセスの最初の反復では、チームのノートブックにゲーム全体の課題の非常に簡単な説明を含め、成功のために達成する必要がある小さな課題に分割する必要があります。ベストプラクティスは、調査またはテストを通じて回答する必要がある質問をリストすることです。たとえば、次のとおりです。

ゲームをプレイするための最も効果的な戦略は何ですか?
ポイントを獲得するにはどのような方法がありますか?
ロボットはどのくらいの速さで動く必要があるのでしょうか?
ロボットはどのようにして得点オブジェクトを拾えるのでしょうか?
ロボットはいくつの得点オブジェクトを保持する必要がありますか?

このプロセスを通じて、チームはロボットに必要な機能のリストと、ゲームの要件と制約のリストを作成する必要があります。たとえば、課題でロボットが物体をできるだけ高く積み上げる必要がある場合、チームはロボットの背を高くすることを決定する可能性があります。ただし、ゲームのマニュアルには、ロボットの高さに関する制限がある場合があります。ブレーンストーミング段階に進む前に、これらすべての基準を検討して理解する必要があります。

設計プロセスの後のサイクルでは、このステップは、期待または必要とされるほど機能していないロボット上の何かを特定し、優れたソリューションには何が含まれるかを説明することになる可能性があります。たとえば、課題は「ボールを得点するためにロボットアームがより高く到達できる必要がある」である場合があり、課題を達成するための目標は「爪の底部が最大 16 メートルまで到達できなければならない」である可能性があります。ボールを持つとき。このチャレンジの制約は、サイズや垂直方向の拡張制限など、ゲームのより大きな制約と重なる場合があります。

ブレーンストーミング & 図

優れたブレーンストーミングは、すべての要件と制約を含め、問題を共通に理解することから始まります。問題を理解していないと、当面の基本的な問題を満たさない無関係なアイデアに時間が無駄になってしまう可能性があります。ブレーンストーミング中は、お互いのアイデアをで判断しないようにすることも重要です。これにより、創造的なプロセスが妨げられ、チームメンバーの参加意欲が低下する可能性があります。

チームのメンバーが問題を完全に理解していないことが明らかになった場合、チームはプロセスの最初のステップ (つまり、「問題を特定する」または「質問する」) からやり直す必要があります。

ブレーンストーミング中に、学生は、ゲームによってもたらされる課題と同様の現実世界からの課題を調査したい場合もあります。また、他のロボット競技会が過去に同様の課題を利用したかどうかを確認することもできます。ブレーンストーミングには、学生が成功するソリューションを作成できるように、他のソースからデータを収集することが含まれます。

有望な解決策は、ラベルを付けた図や写真など、チームのノートに文書化する必要があります。チームが他のソースからアイデアを入手した場合、それらのソースはノートブック内で明確に識別される必要があります。

ソリューションを選択する & 計画を立てる

ブレーンストーミングが完了し、いくつかのアイデアが生成されたら、チームは各アイデアを客観的に評価する必要があります。目標は、ソースに関係なく、チームにとって最適なソリューションを見つけることです。表は、チームが特定の設計上の要望や制約に関連して各アイデアの利点を検討し、比較するのに役立ちます。以下の例では、各基準は 0 ～ 5 ポイントのスケールで評価されます。0 は期待を満たさず、5 は期待を上回ります。「アイデア 4」が総合スコアが最も高いため、客観的な選択となります。

アイデア	基準1	基準2	基準3	基準4	合計スコア
アイデア 1	3	3	2	1	9
アイデア 2	5	5	0	0	10
アイデア 3	1	1	5	5	12
アイデア 4	4	4	4	4	16

チームはこのプロセスをノートブックに文書化し、ソリューションを選択する方法と理由を説明する必要があります。また、ソリューションを構築する方法の計画も含め、エンジニアリングノートにソリューションについて詳しく説明する必要があります。上級チームの場合、この計画には CAD モデルまたは詳細なアセンブリ図面の作成が含まれる場合があります。

ビルド & プログラム

ここはチームがほとんどの時間を費やし、プロトタイプや最終的なロボットやプログラムが作成される場所です。コードとロボットの両方のビルドは、通常、基本設計として開始され、設計プロセスの後のサイクルで詳細が追加されるにつれて進化します。学生は、プログラミングを構築している間、 & に詳細なメモを取り、見たものを記録し、あるものが他のものよりもうまく機能する理由を理解しようとし、その後、追加のプロトタイプまたはプログラムを作成して新しいアイデアをテストする必要があります。データを収集し、それをノートブックに記録することは、構築とプログラミングの重要な部分です。

ソリューションをテストする

このステップでは、学生は自分が構築またはプログラムしたものをテストして、何が機能し、何が機能しないのか、何が改善できるのかを確認します。テスト手順はノートに詳しく文書化され、測定可能な結果がすべて含まれている必要があります。このステップの主な目的は、ビルドまたはコードが課題を満たしており、期待どおりに必要に応じて実行されるかどうかを判断することです。

設計プロセスを繰り返す

テストで何かが機能しない場合はどうなりますか? 学生は問題を分析して、それがもたらす新たな課題を特定し、設計プロセスの新しいサイクルを開始します。

すべての設計プロセスサイクルですべてのステップが必要なわけではなく、ステップからステップへとジャンプしたり、次のステップに進む前にステップを複数回繰り返したりする場合もあります。設計チームは、設計プロセスを後戻りすることを恐れるべきではありません。最終的な目標は、何度も改善を繰り返しながら、可能な限り最高のデザインを作成することです。設計サイクルも、特にロボットのサブシステムとコードの間で重複する可能性があります。チームは、ノートブックにエントリを作成する際に、どの設計プロセスステップで作業しているかを最善を尽くして特定する必要があります。

では、チームはロボットの完成時期をどのように決定するのでしょうか? シンプル: チームはスケジュールを設定し、それを遵守する必要があります。このスケジュールはチームの状況に応じてチームごとに大きく異なります。最初の競技会までにチームがロボットの設計と製作に 6 週間の猶予がある場合、この期間について何らかのスケジュールを立てる必要があります。構築プロセスの各ステップを計画するチームもあれば、概要を簡単に説明するだけのチームもいます。

スケジュールは常に決まっているわけではありません。最終的に固定される日付は、プロジェクトの開始日とロボットの完成期限 (通常はコンテストの日) だけです。プロセスが進むにつれて、他のすべてが変化する可能性があります。