VRC technisch ontwerpproces

Het technische ontwerpproces is een reeks stappen die ingenieurs volgen wanneer ze een probleem proberen op te lossen en ergens een oplossing voor proberen te ontwerpen; het is een methodische benadering van het oplossen van problemen. Er bestaat niet één universeel geaccepteerd ontwerpproces, en de meeste ingenieurs hebben hun eigen draai aan de manier waarop het proces werkt. Het proces begint doorgaans met een probleem en eindigt met een oplossing, maar de middelste stappen kunnen variëren.

Een gemeenschappelijk kenmerk van de meeste ontwerpprocessen is dat ze iteratief zijn en dat ontwerpers mogelijk terug moeten gaan naar eerdere stappen in het proces en/of het hele proces steeds opnieuw moeten herhalen totdat ze tot een minimaal haalbare oplossing komen.

Het technische ontwerpproces dat in dit artikel wordt beschreven, is niet de enige juiste versie van het proces, het is slechts één voorbeeld. Het moet een goed startpunt bieden voor studenten om het engineeringproces te verkennen.

Een heel eenvoudig ontwerpproces omvat mogelijk slechts 3 stappen, zoals hieronder weergegeven: Definiëren, oplossingen ontwikkelen en optimaliseren (deze illustratie is beschikbaar als poster op volledige grootte op posters.vex.com als u er een voor uw klaslokaal wilt!).

Een ander voorbeeld van een ontwerpproces is Projectleider The Way's Gateway-ontwerpproces.

Stappen van het technische ontwerpproces

Voor dit artikel zullen we een ontwerpproces overwegen dat overeenkomt met waar juryleden naar op zoek zijn bij het interviewen van teams en het beoordelen van hun technische notitieboekjes tijdens REC Foundation-wedstrijden.

Identificeer de uitdaging & Stel doelen

Dit wordt ook wel ‘Vraag’ of ‘Definieer’ genoemd. Het identificeren van de uitdaging moet altijd de eerste stap zijn die in het ontwerpproces wordt aangepakt. 

Voor de eerste versie van het ontwerpproces moet het notitieboekje van het team een ​​zeer korte beschrijving bevatten van de algehele game-uitdaging en deze opsplitsen in kleinere uitdagingen die moeten worden volbracht voor succes. De beste praktijk is om vragen op te sommen die beantwoord moeten worden door middel van onderzoek of testen, bijvoorbeeld:

• Wat is de meest effectieve strategie om het spel te spelen?
• Wat zijn de manieren om punten te scoren?
• Hoe snel moet de robot bewegen?
• Hoe kan de robot de scoreobjecten oppakken?
• Hoeveel scoreobjecten moet de robot vasthouden?

Via dit proces moeten teams een lijst met functies bedenken die ze mogelijk in hun robot willen hebben, en een lijst met de vereisten en beperkingen van het spel. Als een robot bijvoorbeeld voor een uitdaging objecten zo hoog mogelijk moet stapelen, kan het team besluiten dat de robot groot moet zijn. De spelhandleiding kan echter een beperking bevatten over hoe groot de robot op een bepaald moment mag zijn. Al deze criteria moeten worden onderzocht en begrepen voordat u doorgaat naar de brainstormfase.

Voor latere cycli van het ontwerpproces kan deze stap bestaan ​​uit het identificeren van iets aan de robot dat niet zo goed werkt als verwacht of nodig is, en het beschrijven van wat een goede oplossing zou inhouden. Een uitdaging kan bijvoorbeeld zijn: 'De robotarm moet hoger kunnen reiken om de bal te scoren', en een doel om de uitdaging te volbrengen kan zijn: 'De onderkant van de klauw moet in staat zijn om tot 16 centimeter te reiken'. "als je een bal vasthoudt." Beperkingen voor deze uitdaging kunnen grotere beperkingen uit het spel overlappen, bijvoorbeeld de grootte en verticale uitbreidingslimieten.

Brainstorm & diagram

Goed brainstormen begint met een gedeeld begrip van het probleem, inclusief alle vereisten en beperkingen. Zonder het probleem te begrijpen, kan tijd worden verspild aan irrelevante ideeën die het fundamentele probleem niet bevredigen. Tijdens het brainstormen is het ook belangrijk om te voorkomenjeideeën beoordeelt. Dit kan het creatieve proces belemmeren en teamleden ervan weerhouden deel te nemen.

Als het duidelijk wordt dat leden van het team het probleem niet volledig begrijpen, moet het team opnieuw beginnen bij de eerste stap van het proces (dat wil zeggen: “Identificeer het probleem” of “Vraag het”).

Tijdens het brainstormen willen leerlingen misschien ook uitdagingen uit de echte wereld onderzoeken die vergelijkbaar zijn met die van het spel. Ze kunnen ook kijken of andere robotica-competities in het verleden soortgelijke uitdagingen hebben gebruikt. Brainstormen omvat het verzamelen van gegevens uit andere bronnen om leerlingen te helpen een succesvolle oplossing te creëren.

Veelbelovende oplossingen moeten worden gedocumenteerd in het notitieboekje van het team, inclusief gelabelde tekeningen of afbeeldingen. Als het team ideeën uit andere bronnen haalt, moeten die bronnen duidelijk in het notitieboekje worden vermeld.

Kies een oplossing & Maak een plan

Zodra het brainstormen is voltooid en er verschillende ideeën zijn gegenereerd, moeten teams elk idee objectief evalueren. Het doel is om de beste oplossing voor het team te vinden, ongeacht de bron. Een tabel kan teams helpen de voordelen van elk idee te overwegen en te vergelijken in relatie tot specifieke ontwerpwensen en -beperkingen. In het onderstaande voorbeeld wordt elk criterium geëvalueerd op een schaal van 0 tot 5 punten, waarbij 0 niet voldoet en 5 de verwachtingen overtreft. Omdat “Idee 4” de hoogste totaalscore heeft, zou dit de objectieve keuze zijn.

Het team moet dit proces in het notitieboekje documenteren en uitleggen hoe en waarom ze voor hun oplossing kiezen. Ze moeten de oplossing ook volledig beschrijven in hun technische notitieboekje, inclusief een plan voor hoe ze deze gaan bouwen. Voor gevorderde teams kan dit plan het maken van CAD-modellen of gedetailleerde montagetekeningen omvatten.

Bouw & programma

Dit is waar teams het grootste deel van hun tijd zullen doorbrengen en waar prototypes en definitieve robots en programma's worden gemaakt. Builds – zowel voor code als voor robots – beginnen over het algemeen als basisontwerpen en evolueren naarmate details worden toegevoegd in latere cycli van het ontwerpproces. Leerlingen moeten gedetailleerde aantekeningen maken in hun notitieboekje terwijl ze programmeren bouwen, vastleggen wat ze zien, proberen uit te vinden waarom sommige dingen beter werken & andere, en vervolgens aanvullende prototypes of programma's maken om nieuwe ideeën te testen. Het verzamelen van gegevens en het vastleggen ervan in de notebook is een belangrijk onderdeel van het bouwen en programmeren.

Test de oplossing

Tijdens deze stap testen leerlingen wat ze hebben gebouwd of geprogrammeerd om te zien wat werkt, wat niet en wat kan worden verbeterd. Testprocedures moeten goed gedocumenteerd zijn in het notebook en moeten alle meetbare resultaten bevatten. Het belangrijkste doel van deze stap is om te beslissen of de build of code aan de uitdaging voldoet en presteert zoals verwacht en nodig is.

Herhaal het ontwerpproces

Wat gebeurt er als iets tijdens het testen niet werkt? Studenten analyseren het probleem om de nieuwe uitdaging die het met zich meebrengt te identificeren, en ze starten een nieuwe cyclus van het ontwerpproces!

Niet alle ontwerpprocescycli hebben alle stappen nodig, en sommige kunnen van stap naar stap springen of een stap meerdere keren herhalen voordat ze naar de volgende gaan. Ontwerpteams moeten niet bang zijn om achteruit te gaan in het ontwerpproces. Het uiteindelijke doel is om het best mogelijke ontwerp te creëren door het steeds opnieuw te verbeteren. Ontwerpcycli zullen waarschijnlijk ook overlappen, vooral tussen robotsubsystemen en code. Teams moeten hun best doen om te bepalen in welke stap(pen) van het ontwerpproces ze werken terwijl ze gegevens in het notitieboekje invoeren.

Dus hoe beslist een team wanneer hun robot klaar is?  Simpel: het team moet een schema opstellen en zich daar vervolgens aan houden. Dit schema zal sterk variëren van team tot team, afhankelijk van hun omstandigheden. Als een team vóór de eerste wedstrijd zes weken de tijd heeft om hun robot te ontwerpen en te bouwen, moeten ze voor deze periode een soort schema opstellen. Sommige teams plannen elke stap in hun bouwproces, terwijl anderen slechts een kort overzicht maken.

Het schema ligt niet altijd in steen gebeiteld; uiteindelijk zijn de enige vaste data de startdatum van het project en de deadline voor voltooiing van de robot (meestal de datum van een wedstrijd). Al het andere zal waarschijnlijk veranderen naarmate het proces zich ontvouwt.