VRC Mühendislik Tasarım Süreci

Mühendislik tasarım süreci, mühendislerin bir sorunu çözmeye ve bir şey için çözüm tasarlamaya çalışırken takip ettikleri bir dizi adımdır; problem çözmede metodik bir yaklaşımdır. Evrensel olarak kabul edilen tek bir tasarım süreci yoktur ve çoğu mühendisin sürecin nasıl işlediğine dair kendi fikirleri vardır. Süreç genellikle bir sorunla başlar ve çözümle biter ancak orta adımlar farklılık gösterebilir.

Çoğu tasarım sürecinin ortak özelliği, yinelemeli olmaları ve tasarımcıların süreçteki önceki adımlara geri dönmeleri ve/veya minimum düzeyde uygulanabilir bir çözüme ulaşana kadar tüm süreci tekrar tekrar tekrarlamaları gerekebilmesidir.

Bu makalede özetlenen mühendislik tasarım süreci, sürecin tek doğru versiyonu değil, sadece bir örnektir. Öğrencilerin mühendislik sürecini keşfetmeleri için iyi bir başlangıç ​​noktası sağlamalıdır.

Çok basit bir tasarım süreci aşağıda gösterildiği gibi yalnızca 3 adım içerebilir: Tanımla, Çözüm Geliştir ve Optimize Et (sınıfınız için bir tane istiyorsanız bu illüstrasyon, posters.vex.com adresinde tam boyutlu bir poster olarak mevcuttur!).

Bir diğer tasarım süreci örneği ise Proje Yolun Ağ Geçidi Tasarım Sürecine Liderlik Etmesi.

Mühendislik Tasarım Sürecinin Adımları

Bu makale için, REC Vakfı yarışmalarında jüri üyelerinin takımlarla röportaj yaparken ve mühendislik defterlerini incelerken aradıkları şeyle eşleşen bir tasarım sürecini ele alacağız.

Mücadeleyi Belirleyin & Hedefleri Belirleyin

Buna bazen "Sor" veya "Tanımla" denir. Zorluğun belirlenmesi her zaman tasarım sürecinde ele alınan ilk adım olmalıdır. 

Tasarım sürecinin ilk yinelemesinde, ekibin not defteri genel oyun mücadelesinin çok kısa bir tanımını içermeli ve bunu başarı için başarılması gereken daha küçük zorluklara ayırmalıdır. En iyi uygulama, araştırma veya test yoluyla yanıtlanması gereken soruları listelemektir; örneğin:

• Oyunu oynamak için en etkili strateji nedir?
• Puan kazanmanın yolları nelerdir?
• Robotun ne kadar hızlı hareket etmesi gerekiyor?
• Robot puanlama nesnelerini nasıl alabilir?
• Robotun kaç tane puanlama nesnesi tutması gerekiyor?

Bu süreç boyunca takımlar, robotlarında isteyebilecekleri özelliklerin bir listesini ve oyunun gereksinimleri ve kısıtlamalarının bir listesini oluşturmalıdır. Örneğin, bir robotun nesneleri olabildiğince yükseğe istiflemesi gerekiyorsa ekip, robotlarının uzun olmasını istediğine karar verebilir. Ancak oyun kılavuzunda robotun herhangi bir zamanda ne kadar uzun olabileceği konusunda bir kısıtlama olabilir. Beyin fırtınası aşamasına geçmeden önce bu kriterlerin tümü araştırılmalı ve anlaşılmalıdır.

Tasarım sürecinin daha sonraki döngüleri için bu adım, robotta beklendiği veya ihtiyaç duyulduğu kadar çalışmayan bir şeyi tanımlamak ve iyi bir çözümün neleri içereceğini açıklamak olabilir. Örneğin, bir meydan okuma şu olabilir: "Robot kolunun topa gol atmak için daha yükseğe ulaşabilmesi gerekiyor" ve bu mücadeleyi gerçekleştirme hedefi ise "Pençenin alt kısmının 16 metreye kadar ulaşabilmesi gerekiyor" olabilir. "topu tutarken." Bu mücadelenin kısıtlamaları, oyundaki boyut ve dikey genişletme sınırları gibi daha büyük kısıtlamalarla örtüşebilir.

Beyin Fırtınası & Diyagramı

İyi bir beyin fırtınası, tüm gereksinimler ve kısıtlamalar dahil olmak üzere sorunun ortak bir şekilde anlaşılmasıyla başlar. Sorun anlaşılmadan, eldeki temel sorunu çözmeyen alakasız fikirler üzerinde zaman harcanabilir. Beyin fırtınası sırasındafikirlerini yargılamaktanda önemlidir. Bu, yaratıcı süreci engelleyebilir ve ekip üyelerinin katılımını engelleyebilir.

Ekip üyelerinin sorunu tam olarak anlamadığı ortaya çıkarsa, ekip sürecin ilk adımıyla baştan başlamalıdır (yani "Sorunu tanımlayın" veya "Sor").

Beyin fırtınası sırasında öğrenciler, oyunun ortaya koyduğuna benzer, gerçek dünyadaki zorlukları da araştırmak isteyebilirler. Ayrıca geçmişte başka robotik yarışmalarının benzer zorluklardan faydalanıp faydalanmadığını da görebilirler. Beyin fırtınası, öğrencilerin başarılı bir çözüm oluşturmasına yardımcı olmak için diğer kaynaklardan veri toplamayı içerir.

Gelecek vaat eden çözümler, etiketli çizimler veya resimler de dahil olmak üzere ekibin not defterinde belgelenmelidir. Ekibin başka kaynaklardan fikir alması durumunda bu kaynaklar not defterinde açıkça belirtilmelidir.

Bir Çözüm Seçin & Plan Yapın

Beyin fırtınası tamamlandıktan ve çeşitli fikirler üretildikten sonra ekipler her fikri objektif olarak değerlendirmelidir. Amaç, kaynak ne olursa olsun ekip için en iyi çözümü bulmaktır. Bir tablo, ekiplerin her fikrin değerini belirli tasarım arzuları ve kısıtlamalarıyla ilişkili olarak değerlendirmesine ve karşılaştırmasına yardımcı olabilir. Aşağıdaki örnekte her kriter, 0'ın karşılamadığı ve 5'in beklentileri aştığı 0-5 puanlık bir ölçekte değerlendirilir. “Fikir 4” en yüksek genel puana sahip olduğundan objektif bir seçim olacaktır.

Ekip bu süreci not defterine belgelemeli ve çözümlerini nasıl ve neden seçtiklerini açıklamalıdır. Ayrıca, çözümü nasıl oluşturacaklarına dair bir plan da dahil olmak üzere, mühendislik defterlerinde çözümü tam olarak açıklamalıdırlar. İleri düzey ekipler için bu plan, CAD modelleri oluşturmayı veya ayrıntılı montaj çizimlerini içerebilir.

& Programı Oluştur

Burası ekiplerin zamanlarının çoğunu harcayacağı ve prototiplerin, son robotların ve programların oluşturulduğu yerdir. Hem kod hem de robotlara yönelik yapılar genellikle temel tasarımlar olarak başlar ve tasarım sürecinin sonraki döngülerinde ayrıntılar eklendikçe gelişir. Öğrenciler & programlamayı oluştururken, gördüklerini kaydederken, bazı şeylerin neden diğerlerinden daha iyi çalıştığını anlamaya çalışırken ve ardından yeni fikirleri test etmek için ek prototipler veya programlar oluştururken not defterlerine ayrıntılı notlar almalıdır. Veri toplamak ve not defterine kaydetmek, oluşturma ve programlamanın önemli bir parçasıdır.

Çözümü Test Edin

Bu adım sırasında öğrenciler neyin işe yaradığını, neyin yaramadığını ve nelerin geliştirilebileceğini görmek için oluşturdukları veya programladıkları şeyleri test edeceklerdir. Test prosedürleri not defterinde iyi bir şekilde belgelenmeli ve ölçülebilir tüm sonuçları içermelidir. Bu adımın temel amacı, yapının veya kodun zorluğu karşılayıp karşılamadığına ve beklendiği ve ihtiyaç duyulan şekilde performans gösterip göstermediğine karar vermektir.

Tasarım Sürecini Tekrarlayın

Bir şey testte işe yaramazsa ne olur? Öğrenciler, ortaya çıkardığı yeni zorluğu belirlemek için sorunu analiz eder ve tasarım sürecinde yeni bir döngü başlatırlar!

Tüm tasarım süreci döngüleri tüm adımlara ihtiyaç duymaz ve bazıları adımdan adıma atlayabilir veya bir sonraki adıma geçmeden önce bir adımı birden çok kez tekrarlayabilir. Tasarım ekipleri tasarım sürecinde geriye gitmekten korkmamalıdır. Nihai amaç, mümkün olan en iyi tasarımı tekrar tekrar geliştirerek yaratmaktır. Tasarım döngüleri de muhtemelen özellikle robot alt sistemleri ve kod arasında örtüşecektir. Takımlar not defterine giriş yaparken hangi tasarım süreci adım(lar)ında çalıştıklarını belirlemek için ellerinden geleni yapmalıdır.

Peki bir ekip robotunun işinin ne zaman biteceğine nasıl karar verir?  Basit: Ekibin bir program belirlemesi ve ardından buna bağlı kalması gerekiyor. Bu program, şartlarına bağlı olarak takımdan takıma büyük ölçüde değişecektir. Bir takımın ilk yarışmadan önce robotunu tasarlamak ve inşa etmek için altı haftası varsa, bu süre için bir tür program hazırlamaları gerekir. Bazı ekipler yapım süreçlerindeki her adımı planlayacak, diğerleri ise sadece hızlı bir genel bakış yapacak.

Program her zaman sabit değildir; sonuçta sabit olan tek tarih, projenin başlangıç ​​tarihi ve robotun tamamlanma tarihidir (genellikle bir yarışmanın tarihi). Süreç ilerledikçe diğer her şeyin değişmesi muhtemeldir.