VRC:n suunnitteluprosessi

Suunnitteluprosessi on sarja vaiheita, joita insinöörit seuraavat yrittäessään ratkaista ongelman ja suunnitella ratkaisun jollekin; se on menetelmällinen lähestymistapa ongelmanratkaisuun. Ei ole olemassa yhtä yleisesti hyväksyttyä suunnitteluprosessia, ja useimmilla insinööreillä on oma kierre prosessin toimivuudesta. Prosessi alkaa yleensä ongelmasta ja päättyy ratkaisuun, mutta keskivaiheet voivat vaihdella.

Yksi yhteinen piirre useimmille suunnitteluprosesseille on, että ne ovat iteratiivisia ja suunnittelijat saattavat joutua palaamaan prosessin aikaisempiin vaiheisiin ja/tai toistamaan koko prosessia yhä uudelleen ja uudelleen, kunnes he saavuttavat minimaalisen elinkelpoisen ratkaisun.

Tässä artikkelissa kuvattu suunnitteluprosessi ei ole ainoa oikea versio prosessista, se on vain yksi esimerkki. Sen pitäisi tarjota opiskelijoille hyvä lähtökohta tutkia suunnitteluprosessia.

Hyvin yksinkertainen suunnitteluprosessi voi sisältää vain 3 alla näkyvää vaihetta: Määrittele, Kehitä ratkaisuja ja Optimoi (tämä kuva on saatavilla täysikokoisena julisteena osoitteessa posters.vex.com , jos haluat sellaisen luokkahuoneeseesi!).

Toinen esimerkki suunnitteluprosessista on Project Lead The Way's Gateway -suunnitteluprosessi.

Suunnitteluprosessin vaiheet

Tässä artikkelissa tarkastelemme suunnitteluprosessia, joka vastaa sitä, mitä tuomarit etsivät haastatellessaan ryhmiä ja tarkistaessaan heidän teknisiä muistikirjojaan REC Foundation -kilpailuissa.

Tunnista haaste & Aseta tavoitteet

Tätä kutsutaan joskus "Kysy" tai "Määritä". Haasteen tunnistamisen tulisi aina olla ensimmäinen askel, joka otetaan huomioon suunnitteluprosessissa. 

Suunnitteluprosessin ensimmäisessä iteraatiossa joukkueen muistikirjaan tulee sisältyä hyvin lyhyt kuvaus koko pelin haasteesta ja jakaa se pienempiin haasteisiin, jotka on suoritettava menestyäkseen. Paras käytäntö on luetella kysymyksiä, joihin on vastattava tutkimuksen tai testauksen avulla, esimerkiksi:

• Mikä on tehokkain strategia pelin pelaamiseen?
• Mitä tapoja kerätä pisteitä?
• Kuinka nopeasti robotin täytyy liikkua?
• Kuinka robotti voi poimia pisteytyskohteita?
• Kuinka monta pisteytyskohdetta robotin pitää pitää?

Tämän prosessin aikana joukkueiden tulee laatia luettelo ominaisuuksista, joita he saattavat haluta robottiinsa, sekä luettelot pelin vaatimuksista ja rajoituksista. Jos esimerkiksi haaste vaatii robotin pinoamaan esineitä mahdollisimman korkealle, tiimi saattaa päättää, että he haluavat robottinsa olevan pitkä. Pelin käsikirjassa voi kuitenkin olla rajoitus siihen, kuinka pitkä robotti voi kulloinkin olla. Kaikki nämä kriteerit tulee tutkia ja ymmärtää ennen kuin siirrytään aivoriihivaiheeseen.

Suunnitteluprosessin myöhemmissä jaksoissa tämä vaihe voi olla tunnistaa robotista jotain, joka ei toimi odotetusti tai tarvittavalla tavalla, ja kuvailla, mitä hyvä ratkaisu sisältää. Haasteena voi olla esimerkiksi se, että "Robotin käden on kyettävä kurkottamaan korkeammalle pallon maalin tekemiseksi", ja haasteen saavuttamisen tavoite voi olla "Kynnen pohjan on voitava yltää jopa 16 "kun pidät palloa." Tämän haasteen rajoitukset voivat olla päällekkäisiä pelin suurempien rajoitusten kanssa, kuten koko ja pystysuuntaiset laajennusrajoitukset.

Aivoriihi & -kaavio

Hyvä aivoriihi alkaa ongelman yhteisymmärryksestä, mukaan lukien kaikki vaatimukset ja rajoitukset. Ilman ongelman ymmärtämistä, aikaa voidaan hukata epäolennaisiin ideoihin, jotka eivät tyydytä käsillä olevaa perusongelmaa. Aivoriihien aikana on myös tärkeää välttääarvostelemasta toistensa ideoita. Tämä voi tukahduttaa luovan prosessin ja estää tiimin jäseniä osallistumasta.

Jos käy selväksi, että tiimin jäsenet eivät täysin ymmärrä ongelmaa, tiimin tulee aloittaa alusta prosessin ensimmäisestä vaiheesta (eli "Tunnista ongelma" tai "Kysy").

Aivoriihen aikana opiskelijat saattavat haluta myös tutkia todellisen maailman haasteita, jotka ovat samanlaisia ​​kuin pelin aiheuttama. He voivat myös katsoa, ​​onko muissa robotiikkakilpailuissa aiemmin käytetty vastaavia haasteita. Aivoriihi sisältää tietojen keräämisen muista lähteistä, jotta opiskelijat voivat luoda onnistuneen ratkaisun.

Lupaavat ratkaisut tulee dokumentoida ryhmän muistikirjaan, mukaan lukien merkittyjä piirustuksia tai kuvia. Jos tiimi saa ideoita muista lähteistä, ne tulee merkitä selkeästi muistikirjaan.

Valitse ratkaisu & Tee suunnitelma

Kun aivoriihi on saatu päätökseen ja useita ideoita on syntynyt, ryhmien tulee arvioida jokainen idea objektiivisesti. Tavoitteena on löytää tiimille paras ratkaisu lähteestä riippumatta. Taulukko voi auttaa tiimejä pohtimaan ja vertailemaan kunkin idean ansioita suhteessa tiettyihin suunnittelutoiveisiin ja rajoituksiin. Alla olevassa esimerkissä jokainen kriteeri on arvioitu 0-5 pisteen asteikolla, jossa 0 ei täytä ja 5 ylittää odotukset. Koska "Idea 4" on korkein kokonaispistemäärä, se olisi objektiivinen valinta.

Työryhmän tulee dokumentoida tämä prosessi muistikirjaan ja selittää, kuinka ja miksi he valitsevat ratkaisunsa. Heidän tulee myös kuvata ratkaisu kokonaisuudessaan suunnittelumuistikirjassaan, mukaan lukien suunnitelma sen rakentamisesta. Edistyneille ryhmille tämä suunnitelma voi sisältää CAD-mallien tai yksityiskohtaisten kokoonpanopiirustusten luomisen.

Build & -ohjelma

Täällä tiimit viettävät suurimman osan ajastaan, ja siellä luodaan prototyyppejä ja lopullisia robotteja ja ohjelmia. Rakennukset – sekä koodia että robotteja varten – alkavat yleensä perussuunnitelmina ja kehittyvät, kun yksityiskohtia lisätään suunnitteluprosessin myöhemmissä jaksoissa. Opiskelijoiden tulee tehdä yksityiskohtaisia ​​muistiinpanoja muistikirjaansa rakentaessaan & ohjelmointia, tallentaessaan näkemäänsä, yrittäessään selvittää, miksi jotkut asiat toimivat paremmin kuin toiset, ja luomalla sitten uusia prototyyppejä tai ohjelmia testatakseen uusia ideoita. Tietojen kerääminen ja tallentaminen muistikirjaan on tärkeä osa rakentamista ja ohjelmointia.

Testaa ratkaisu

Tämän vaiheen aikana opiskelijat testaavat, mitä he ovat rakentaneet tai ohjelmoineet nähdäkseen, mikä toimii, mikä ei ja mitä voidaan parantaa. Testausmenettelyt tulee dokumentoida hyvin muistikirjaan, ja niiden tulee sisältää kaikki mitattavissa olevat tulokset. Tämän vaiheen päätavoite on päättää, vastaako koontiversio tai koodi haasteeseen ja toimiiko odotetusti ja tarpeen mukaan.

Toista suunnitteluprosessi

Mitä tapahtuu, kun jokin ei toimi testauksessa? Opiskelijat analysoivat ongelmaa tunnistaakseen sen tuoman uuden haasteen ja aloittavat uuden suunnitteluprosessin syklin!

Kaikki suunnitteluprosessin syklit eivät vaadi kaikkia vaiheita, ja jotkut voivat hypätä vaiheesta toiseen tai toistaa vaiheen useita kertoja ennen kuin siirrytään seuraavaan. Suunnittelutiimien ei pitäisi pelätä mennä taaksepäin suunnitteluprosessissa. Lopullisena tavoitteena on luoda paras mahdollinen muotoilu parantamalla sitä yhä uudelleen ja uudelleen. Suunnittelusyklit menevät myös todennäköisesti päällekkäin, etenkin robottialijärjestelmien ja koodin välillä. Tiimien tulee tehdä parhaansa tunnistaakseen, missä suunnitteluprosessin vaiheissa he työskentelevät tehdessään merkintöjä muistikirjaan.

Joten miten tiimi päättää, milloin heidän robottinsa on valmis?  Yksinkertaista: tiimin on asetettava aikataulu ja sitten pysyttävä siinä. Tämä aikataulu vaihtelee suuresti joukkueittain olosuhteiden mukaan. Jos joukkueella on kuusi viikkoa aikaa suunnitella ja rakentaa robottinsa ennen ensimmäistä kilpailua, heidän tulisi laatia jonkinlainen aikataulu tälle ajanjaksolle. Jotkut tiimit suunnittelevat jokaisen rakennusprosessinsa vaiheen, kun taas toiset tekevät vain nopean yleiskatsauksen.

Aikataulu ei ole aina kiveen hakattu; lopulta ainoat kiinteät päivämäärät ovat projektin aloituspäivä ja robotin valmistumispäivämäärä (yleensä kilpailun päivämäärä). Kaikki muu todennäköisesti muuttuu prosessin edetessä.