VRC mérnöki tervezési folyamat

A mérnöki tervezési folyamat olyan lépések sorozata, amelyeket a mérnökök követnek, amikor megpróbálnak megoldani egy problémát, és valamire megoldást terveznek; ez a problémamegoldás módszeres megközelítése. Nincs egyetlen általánosan elfogadott tervezési folyamat, és a legtöbb mérnöknek megvan a maga csavarja a folyamat működéséhez. A folyamat általában egy problémával kezdődik és megoldással ér véget, de a középső lépések változhatnak.

A legtöbb tervezési folyamat egyik közös jellemzője, hogy iteratívak, és előfordulhat, hogy a tervezőknek vissza kell térniük a folyamat korábbi lépéseihez, és/vagy újra és újra meg kell ismételnie a teljes folyamatot, amíg el nem jutnak egy minimálisan életképes megoldáshoz.

Az ebben a cikkben felvázolt mérnöki tervezési folyamat nem az egyetlen helyes változata a folyamatnak, ez csak egy példa. Jó kiindulási alapot kell nyújtania a hallgatóknak a mérnöki folyamat felfedezéséhez.

Egy nagyon egyszerű tervezési folyamat csak 3 lépésből állhat, az alábbiak szerint: Meghatározás, Megoldások fejlesztése és Optimalizálás (ez az ábra teljes méretű poszterként érhető el a posters.vex.com címen, ha szeretne egyet az osztálytermébe!).

Egy másik példa a tervezési folyamatra a Project Lead The Way's Gateway tervezési folyamat.

A mérnöki tervezési folyamat lépései

Ebben a cikkben egy olyan tervezési folyamatot vizsgálunk meg, amely megfelel annak, amit a bírák keresnek, amikor a csapatokkal interjúznak és átnézik a mérnöki jegyzetfüzeteiket a REC Foundation versenyein.

Határozza meg a & kihívást, és állítsa be a célokat

Ezt néha „Kérdés”-nek vagy „Definiálásnak” is nevezik. A tervezési folyamat első lépéseként mindig a kihívás azonosítása kell, hogy legyen. 

A tervezési folyamat első iterációja során a csapat jegyzetfüzetének tartalmaznia kell a teljes játék kihívásának nagyon rövid leírását, és azt kisebb kihívásokra kell lebontani, amelyeket a sikerhez teljesíteni kell. A legjobb gyakorlat az, ha felsorolja azokat a kérdéseket, amelyekre kutatással vagy teszteléssel kell válaszolni, például:

• Mi a leghatékonyabb stratégia a játékhoz?
• Milyen módjai vannak a pontszerzésnek?
• Milyen gyorsan kell mozognia a robotnak?
• Hogyan tudja a robot felvenni a pontozó tárgyakat?
• Hány pontozó tárgyat kell tartania a robotnak?

Ezen a folyamaton keresztül a csapatoknak össze kell állítaniuk egy listát a robotjukban esetleg szükséges funkciókról, valamint a játék követelményeiről és korlátairól. Például, ha egy kihívás megköveteli, hogy egy robot a lehető legmagasabbra rakja az objektumokat, a csapat dönthet úgy, hogy azt akarja, hogy a robot magas legyen. A játék kézikönyve azonban korlátozhatja, hogy a robot milyen magas lehet egy adott időpontban. Mindezeket a kritériumokat fel kell fedezni és meg kell érteni, mielőtt az ötletbörze szakaszba lépnénk.

A tervezési folyamat későbbi ciklusaiban ez a lépés az lehet, hogy azonosítani kell valamit a roboton, ami nem működik a vártnak vagy szükségesnek megfelelően, és leírni, hogy mit tartalmazna egy jó megoldás. Kihívás lehet például az, hogy „A robotkarnak magasabbra kell nyúlnia ahhoz, hogy megszerezze a labdát”, és a kihívás teljesítésének célja a következő lehet: „A karom aljának képesnek kell lennie arra, hogy elérje a 16-ot. "amikor labdát tartanak." Ennek a kihívásnak a korlátai átfedhetik a játék nagyobb korlátait, például a méret és a függőleges bővítési korlátok.

Brainstorm & diagram

A jó ötletbörze a probléma közös megértésével kezdődik, beleértve az összes követelményt és korlátot. A probléma megértése nélkül az idő elvesztegethető olyan irreleváns ötletekre, amelyek nem elégítik ki az adott alapvető problémát. Az ötletelés során az is fontos, hogy neítélkezzünk egymás ötletein. Ez elfojthatja a kreatív folyamatot, és elriaszthatja a csapattagokat a részvételtől.

Ha világossá válik, hogy a csapat tagjai nem értik teljesen a problémát, a csapatnak elölről kell kezdenie a folyamat első lépését (azaz „Azonosítsa a problémát” vagy „Kérdezzen”).

Az ötletbörze során a tanulók a való világból származó kihívásokat is megvizsgálhatják, amelyek hasonlóak a játék által támasztott kihívásokhoz. Azt is megnézhetik, hogy más robotikai versenyeken használtak-e hasonló kihívásokat a múltban. Az ötletbörze magában foglalja más forrásokból származó adatok gyűjtését, hogy segítse a diákokat egy sikeres megoldás létrehozásában.

Az ígéretes megoldásokat dokumentálni kell a csapat jegyzetfüzetében, beleértve a feliratozott rajzokat vagy képeket. Ha a csapat más forrásokból kap ötleteket, ezeket a forrásokat egyértelműen meg kell jelölni a jegyzetfüzetben.

Válasszon megoldást & Készítsen tervet

Miután az ötletbörze befejeződött, és több ötlet született, a csapatoknak objektíven kell értékelniük minden ötletet. A cél az, hogy forrástól függetlenül megtalálják a legjobb megoldást a csapat számára. Egy táblázat segíthet a csapatoknak az egyes ötletek érdemeinek mérlegelésében és összehasonlításában a konkrét tervezési vágyak és korlátok tekintetében. Az alábbi példában minden kritériumot egy 0-5 pontos skálán értékelünk, ahol a 0 nem felel meg, az 5 pedig meghaladja az elvárásokat. Mivel az „Ötlet 4” a legmagasabb összpontszámmal rendelkezik, ez lenne az objektív választás.

A csapatnak dokumentálnia kell ezt a folyamatot a jegyzetfüzetben, és el kell magyaráznia, hogyan és miért választja a megoldást. Ezenkívül teljes körűen le kell írniuk a megoldást a mérnöki jegyzetfüzetükben, beleértve a megépítési tervet is. Haladó csapatok számára ez a terv tartalmazhat CAD-modelleket vagy részletes összeállítási rajzokat.

Build & program

Itt töltik idejük nagy részét a csapatok, és itt készülnek el a prototípusok és a végleges robotok és programok. Az építések – mind a kódhoz, mind a robotokhoz – általában alapvető tervekként indulnak, és a tervezési folyamat későbbi ciklusaiban a részletekkel együtt fejlődnek. A tanulóknak részletes feljegyzéseket kell készíteniük a jegyzetfüzetükbe, miközben & programozást készítenek, rögzítik a látottakat, próbálják kitalálni, hogy egyes dolgok miért működnek jobban, mint mások, majd további prototípusokat vagy programokat készítsenek az új ötletek tesztelésére. Az adatok összegyűjtése és rögzítése a notebookba az építés és a programozás fontos része.

Tesztelje a megoldást

Ebben a lépésben a diákok tesztelik, hogy mit építettek vagy programoztak, hogy megtudják, mi működik, mi nem, és mi az, ami még javítható. A tesztelési eljárásokat jól dokumentálni kell a notebookban, és tartalmazniuk kell minden mérhető eredményt. Ennek a lépésnek a fő célja annak eldöntése, hogy a build vagy a kód megfelel-e a kihívásnak, és az elvárásoknak és igényeknek megfelelően teljesít-e.

Ismételje meg a tervezési folyamatot

Mi történik, ha valami nem működik a tesztelés során? A hallgatók elemzik a problémát, hogy azonosítsák az új kihívást, és elindítják a tervezési folyamat új ciklusát!

Nem minden tervezési folyamathoz szükséges minden lépés, és néhány lépésről lépésre ugrálhat, vagy többször megismételhet egy lépést, mielőtt a következőre lépne. A tervezőcsapatoknak nem kell félniük attól, hogy visszafelé haladnak a tervezési folyamatban. A végső cél az, hogy a lehető legjobb dizájnt hozzuk létre annak újra és újra tökéletesítésével. A tervezési ciklusok valószínűleg átfedik egymást, különösen a robotalrendszerek és a kód között. A csapatoknak minden tőlük telhetőt meg kell tenniük annak meghatározására, hogy melyik tervezési folyamatban dolgoznak, miközben bejegyzéseket készítenek a jegyzetfüzetbe.

Tehát hogyan dönti el egy csapat, hogy mikor készül el a robotja?  Egyszerű: a csapatnak ütemtervet kell felállítania, majd ragaszkodnia kell hozzá. Ez az ütemterv csapatonként nagymértékben változhat a körülményektől függően. Ha egy csapatnak hat hete van arra, hogy megtervezze és megépítse a robotját az első verseny előtt, akkor valami ütemtervet kell készítenie erre az időszakra. Egyes csapatok megtervezik az építési folyamat minden egyes lépését, míg mások csak egy gyors áttekintést készítenek.

Az ütemterv nincs mindig kőbe vésve; végül az egyetlen rögzített dátum a projekt kezdési dátuma és a robot befejezésének határideje (általában egy verseny dátuma). Valószínűleg minden más megváltozik a folyamat előrehaladtával.