हमने उड़ान सिम्युलेटर कैसे बनाया: एक अमूल्य अनुभव

सभी को नमस्कार!

एक साल पहले की तुलना में थोड़ा कम, मैं एक उपकरण बनाने की प्रक्रिया में शामिल हो गया जो उड़ान सिम्युलेटर और एक पेशेवर उड़ान सिम्युलेटर के बीच कहीं स्थित है। यह पहला अनुभव नहीं था - 2009 में हमने पहले ही इस तरह की समस्या को हल कर लिया था, इसलिए, एक बहुत ही महत्वाकांक्षी सपने को साकार करना शुरू करते हुए, हमने सभी संभव रेक पर कदम नहीं रखने की कोशिश की। यहां मैं "पहले पैनकेक" के साथ पृष्ठभूमि का वर्णन करूंगा, और यह दूसरे को कैसे प्रभावित करेगा। यदि यह दिलचस्प है, तो हम अपने दूसरे सिम्युलेटर के बारे में विस्तार से लिखेंगे।

DIY में एक पोस्ट क्योंकि हम में से किसी को पहले विमान या पेशेवर सिमुलेटर बनाने का अनुभव नहीं था। इसके अलावा, जैसा कि बाद में पता चला, कम बजट की उड़ान सिम्युलेटर के निर्माण के दृष्टिकोण पेशेवर क्षेत्र में दृष्टिकोण से मौलिक रूप से अलग हैं। सामान्य तौर पर, पहले और दूसरे सिम्युलेटर को शौकीनों द्वारा बनाया गया था, हालांकि, एक तकनीकी पृष्ठभूमि के साथ।

सावधानी , विमानन उत्साही और इंजीनियरों के बीच नर्वस टिक के कारण बहुत सारी तस्वीरें।
इसलिए ...

प्रागितिहास

जुलाई 2009 में, मेरे एक परिचित ने फोन किया और कहा कि मास्को में एक व्यवसायी अपने लिए बोइंग 737-800 सिम्युलेटर बना रहा था, और वह सफल नहीं हो रहा था, और वे कहते हैं, क्या मैं परियोजना में भाग लेना चाहूंगा। मैं चाहता था, मैं इस व्यापारी के पास आया, दंग रह गया और तुरंत काम पर लग गया।

मुझे कहना होगा कि परिणामस्वरूप सिम्युलेटर का निर्माण किया गया था, शायद, जितना संभव हो उतना महंगा और रेक की अधिकतम संख्या के साथ। यह हमारे साथ अनुभव की कमी के कारण था, बहुत हद तक - कम लागत वाली उड़ान सिमुलेटरों और उनके घटकों के अत्यंत अविकसित बाजार तक, और, सबसे महत्वपूर्ण बात, हमने योजना नहीं बनाई। यह शुद्ध प्रयोगशाला विज्ञान, घुटने टेकने और अकुशल: हम समय में बेहद सीमित थे।

नतीजतन, बहुत कम से कम, हमारे गर्भनिरोधक जीवन के लिए आया, मैक्स पर दिखाई दिया, और हम सभी पर सवारी करना शुरू कर दिया।

बोइंग के पूरा होने के तुरंत बाद, मैंने कंपनी छोड़ दी और 2012 की गर्मियों में वापस आ गया। मुझे वापस बुलाया गया, क्योंकि उस अद्भुत व्यवसायी ने एक दूसरा सिम्युलेटर बनाने का फैसला किया। इस बार यह एयरबस ए 320 बन गया।

इस बार हमने इस मुद्दे पर अधिक सक्रियता से फैसला किया: योजना बनाने के लिए समय और ऊर्जा खर्च करने के लिए एक संयुक्त निर्णय किया गया। इसके अलावा, मैंने जोर देकर कहा कि कागजात और चित्र पहले दिखाई देते हैं, और उसके बाद ही कई घटकों की खरीद होती है।

बेशक, मुख्य कार्यों में से एक स्वामित्व की कुल लागत को कम करना था, और इसके लिए हमें बोइंग के साथ कदम रखने के बारे में विश्लेषण करने और सोचने की जरूरत थी।

जेली

शुरू करने के लिए, मैंने रेक का विश्लेषण करने का फैसला किया। अंततः, डिजाइन और निर्माण के स्तर पर इन समान रेक ने अप्रत्याशित सिम्युलेटर डाउनटाइम का नेतृत्व किया, जिसके परिणामस्वरूप कंपनी के लिए बहुत ही ध्यान देने योग्य वित्तीय और छवि हानि हुई। दूसरे राउंड में उन्हें बेक करना जरूरी नहीं था।

आईटी अवसंरचना का अभाव

वास्तव में, जब बोइंग का जन्म हुआ, तो यह माना गया कि "सब कुछ अपने आप काम करेगा।" केवल तीन आपूर्तिकर्ता थे: सभी इलेक्ट्रॉनिक्स के साथ एक केबिन, एक मोबाइल प्लेटफ़ॉर्म और एक वीडियो सिस्टम। सॉफ्टवेयर (प्रोजेक्ट मैजंटा अगर कोई इस बारे में कुछ कहता है) केबिन के आपूर्तिकर्ता द्वारा आपूर्ति की गई थी, और तदनुसार बुनियादी ढांचा "ऊपर से हमारे लिए दिया गया था।" जैसा कि ऑपरेशन से पता चला है, यह कम से कम सही ढंग से कंप्यूटर पर बिखरे हुए घटकों के लिए आवश्यक था, लेकिन यह भी नहीं किया गया था।

भविष्य में, निरंतर परिवर्तनों (जो मैं अलग से चर्चा करूंगा) ने प्रणाली को अपने स्वयं के जीवन को ठीक करने के लिए प्रेरित किया है। हर बार किसी प्रकार की विफलता या विफलता थी, मुझे अंततः कई घटकों से एक नोड को खोलना था ताकि अंततः पता लगाया जा सके कि लॉग फ़ाइल एक निश्चित आकार तक पहुंच गई तो उनमें से एक ने काम करना बंद कर दिया।
कोई नियमित बैकअप, घटक संस्करण नियंत्रण की कोई बात नहीं थी।

प्रदर्शन के लिए, जैसा कि नए परिदृश्य स्थापित किए गए थे, सिम्युलेटर के प्रदर्शन में काफी गिरावट आई, जिसके परिणामस्वरूप एक्स-प्लेन के साथ एमएसएफएस के प्रतिस्थापन की आवश्यकता थी। वास्तव में ऐसा चुनाव क्यों किया गया - मुझे नहीं पता, मैंने इसमें भाग नहीं लिया, लेकिन तथ्य यह है।

स्केलेबल एक्स-प्लेन के साथ अखंड एमएसएफएस की जगह लेने के बाद भी, ग्राफिक्स के प्रदर्शन की गणना नहीं की गई थी, जिसके परिणामस्वरूप इन सर्वरों के हार्डवेयर को दो बार अपग्रेड किया गया था।

इस आपदा से, मैंने यह निष्कर्ष निकाला कि संपूर्ण सिम्युलेटर की वास्तुकला को चित्रित करना आवश्यक है, जो घटक किस कंप्यूटर पर काम करेगा, संभव एक्सटेंशन के लिए प्रदान करता है, हार्डवेयर प्रदर्शन की आवश्यकताओं को चित्रित करता है, नेटवर्क लोड का मूल्यांकन करता है और आगे के विकास के लिए एक छोटा सा मार्जिन बनाता है। अंततः, सिम्युलेटर का उद्देश्य लगातार नई तकनीकों को विकसित करना नहीं है, बल्कि ग्राहकों के चेहरे पर मुस्कान है।

सतत परिवर्तन और बहु-विक्रेता

ओह, यह सिर्फ एक छुट्टी है।
जबकि MSFS एक सिम्युलेटर के रूप में इस्तेमाल किया गया था, सब कुछ कम या ज्यादा स्थिर था: मैंने एक स्क्रिप्ट को एक वक्र में रखा - तुरंत सिम्युलेटर का डंप प्राप्त करें। सरल और बिना तामझाम के।

जब हमने एक्स-प्लेन पर स्विच किया और चार प्रतियों को स्थापित करके सिस्टम को स्केल किया (एक गतिशीलता पर विचार करता है, और प्रत्येक अपने स्वयं के प्रोजेक्टर पर अपनी तस्वीर खींचता है), तो यह पता चला कि त्रुटियों के साथ एक ही स्क्रिप्ट को चार प्रतियों में फैलाना अधिक कठिन था। खासकर जब आप समझते हैं कि उनमें से एक विंडोज के तहत काम करता है, और तीन लिनक्स के तहत। त्रुटियां और समस्याएं शुरू हुईं, एक प्रोजेक्टर पर स्क्रिप्ट क्रैश (सबसे अप्रिय)। कुछ बिंदु पर, लिपियों पर नियंत्रण पूरी तरह से खो गया था, और किसी भी एक के साथ सभी स्थापनाओं को पूरी तरह से सिंक्रनाइज़ करने के लिए एक मजबूत-इच्छाशक्ति वाला निर्णय किया गया था। इसने हमें लगभग पूरी तरह से दृश्य के साथ समस्याओं से छुटकारा पाने की अनुमति दी, लेकिन समस्या की जड़ बनी रही - हमारे पास चार अलग-अलग सिम्युलेटर इंस्टॉलेशन हैं, जिनमें से तीन एक स्क्रीन पर एक छवि बनाते हैं।

कभी-कभी लोहा (नियंत्रक) विफल रहा। एक ही चीज़ को समेटने और खरीदने के बजाय, अन्य निर्माताओं से नियंत्रक खरीदे गए। नतीजतन, तीन वर्षों के बाद, बोइंग 5 विक्रेताओं के रूप में कई से सुसज्जित था, और उनमें से प्रत्येक के पास अपनी विशेषताओं के साथ अपना स्वयं का इंटरफ़ेस सॉफ़्टवेयर है। बेशक, यह एक साथ काम करता है, लेकिन कुछ अज्ञात समस्याओं के मामले में, निदान एक जीवित नरक में बदल जाता है।

फिर से, नए नियंत्रक बोर्ड पर नए केबल होते हैं, और कुछ बिंदु पर हमें यह पता चला कि अब हमें नहीं पता है कि यह किस तरह का तार है, यह कहां जाता है और इसके लिए क्या है। मुझे कुछ दिनों के लिए सिम्युलेटर को रोकना पड़ा, और लगभग पूरी तरह से फिर से वायरिंग करना पड़ा।

इस रेक से, मैंने निष्कर्ष निकाला कि सिम्युलेटर का निर्माण किया जाना चाहिए, यदि सदियों तक नहीं, तो कम से कम वर्षों तक। संभावित विकास की दिशाओं का अग्रिम मूल्यांकन करना, उन्हें ठीक करना और इन दिशाओं के आधार पर एक प्रणाली का निर्माण करना आवश्यक है। यदि किसी बिंदु पर किसी अन्य दिशा में कुछ सुधार करने की इच्छा है - ठीक है, तो, कुछ को परिचालन विश्वसनीयता के पक्ष में छोड़ना होगा।

शोषण

सिम्युलेटर का संचालन उस पर समान नहीं था।

कोई ऑपरेटिंग निर्देश नहीं थे, परिवर्तनों पर कोई प्रतिबंध नहीं था, एक बैकअप योजना, अनुसूचित रखरखाव और बहुत सारी चीज़ें नहीं थीं।

अलग-अलग हाथ एक ही सिम्युलेटर में चढ़ गए, सेटिंग्स बदल गई, जल्दी से जाँच की और छोड़ दिया, और अगली सुबह सिम्युलेटर शुरू नहीं हुआ।

प्रोजेक्टर में लैंप सबसे अधिक अनुपयोगी क्षण में बाहर जला दिया गया था, और स्पेयर विडन में कहीं एक स्टोर में थे, और शुक्रवार की शाम को हमारे कूरियर मास्को के माध्यम से मास्को में अंतिम दीपक खरीदने के लिए पहुंचे (चुटकुलों को छोड़कर)।

चलती प्लेटफॉर्म के ड्राइव के सिलेंडरों में तेल चुपचाप बह निकला, और हमने पाया कि यह केवल तब ही बहता है जब फर्श पर एक पोखर का निर्माण हुआ हो। और, ज़ाहिर है, इस ब्रांड का तेल खरीदने का कोई तरीका नहीं था।

सारांश: सिम्युलेटर ने काम किया, लेकिन संचालित नहीं किया। यह टूट जाता है - हम इसे ठीक कर देते हैं। यह टूटता नहीं है - हम उड़ते हैं।

नई परियोजना में, ऑपरेशन प्रक्रिया का पूर्वाभास और वर्णन करना बहुत महत्वपूर्ण था: हमें किन स्पेयर पार्ट्स की जरूरत है, हम कितनी बार डायग्नोस्टिक्स करते हैं, क्या होगा अगर यह टूट जाता है, हम कौन से अपडेट इंस्टॉल करते हैं और कैसे, हम उनका परीक्षण कैसे करते हैं, हम कितनी बार बैकअप करते हैं, आदि। आगे देखते हुए, मैं कहता हूँ कि इस दृष्टिकोण से बहुत मदद मिली। यह पता चला है कि यदि आप कम से कम नियमित बैकअप पर सहमत होते हैं और जब यह भयानक होता है तो परिवर्तन नहीं करते हैं, तो सिस्टम बहुत लंबा और बेहतर रहता है।

बिजली की समस्या

ऐसा लगता है कि इस तरह के तकनीकी रूप से जटिल उपकरण में, बिजली की समस्याओं को ज्यादा जगह नहीं लेनी चाहिए।
अरे नहीं! जब मैं पहली बार बोइंग में शामिल हुआ, तो नियंत्रकों के सहज बंद थे, जिनका हम लंबे समय तक निदान नहीं कर सके। कुछ बिंदु पर, मैंने USB नियंत्रकों के "जमीन" और उस कंप्यूटर के बीच संभावित अंतर को मापने का अनुमान लगाया, जिसमें इस कनेक्टर को प्लग किया गया था: कंप्यूटर के मदरबोर्ड पर नियंत्रक और यूएसबी हब दोनों के लिए बहुत सारे थे। यह पता चला कि किसी अज्ञात तरीके से, हमारे आपूर्तिकर्ता कैब की "भूमि" और कंप्यूटर के साथ रैक को हटाने में कामयाब रहे। उन्होंने "पृथ्वी" की सही वायरिंग के साथ एक बिंदु से ऊर्जा की आपूर्ति की और तटस्थ - डंप की संख्या तेजी से गिर गई।
एक और बार, हमने एक चरण में दस्तक दी, और एक शव परीक्षा से पता चला कि कोई लोड संतुलन नहीं था। उसके बाद, मैंने सिम्युलेटर के सभी घटकों की बिजली आपूर्ति सर्किट का विश्लेषण किया और इसे फिर से किया, समस्या दूर हो गई।

निष्कर्ष एक बिजली आपूर्ति सर्किट की आवश्यकता थी जो भार की गणना और संतुलन के साथ, अबाधित बिजली आपूर्ति के बीच उनके वितरण, और निश्चित रूप से, शॉर्ट-सर्किट और बिजली के झटके से दोनों के संरक्षण के साथ है। पहले, कागज पर, चेक के साथ "क्या होगा अगर यह पोस्टिंग बंद हो जाती है", तारों के क्रॉस-सेक्शन की गणना, मशीनों की रेटिंग और बिजली की चीजों की तरह। और केवल सर्किट में बदलाव नहीं होने के बाद - घटकों की खरीद और एक विद्युत पैनल की विधानसभा।

यूएसबी

हमने कभी नहीं सोचा कि कॉकपिट में कितने बल्ब और बटन हैं, लेकिन इनपुट-आउटपुट नियंत्रकों की संख्या डेढ़ दर्जन से अधिक है। और उनमें से प्रत्येक यूएसबी के साथ समाप्त होता है, और इसे कंप्यूटर में चालू करना चाहिए।
मैंने पहले से ही एक सामान्य "ग्राउंड" की कमी के साथ समस्याओं के बारे में लिखा था, हमने इसे सफलतापूर्वक हल किया, लेकिन जब केबल के तीन बंडल तीन अलग-अलग कंप्यूटरों में जाते हैं, तो कोई समस्या नहीं होती है।
हमने कई अलग-अलग यूएसबी एक्सटेंशन डोरियों की कोशिश की, विभिन्न निर्माताओं से हब स्थापित करने की कोशिश की, एक कंप्यूटर पर सभी उपकरणों को इकट्ठा करने की कोशिश की, सामान्य तौर पर, बहुत सी चीजों की कोशिश की, लेकिन सबसे असंगत क्षण में यूएसबी डिवाइस के "गिरने" से समस्या, हालांकि दुर्लभ बनी हुई है इस दिन।

स्पष्ट निष्कर्ष यूएसबी के उपयोग की अस्वीकृति थी, लेकिन जैसा कि मैंने कहा, हमारे प्रबुद्ध युग में कम बजट वाले सिमुलेटरों के लिए बाजार (यानी, जो निजी व्यक्तियों को खर्च कर सकते हैं, $ 50k तक की लागत) बेहद अविकसित है, और यूएसबी वहां शासन करता है। इसके अलावा, घटकों के आपूर्तिकर्ताओं में से कोई भी ध्यान में रखता है कि केबिन स्थानांतरित हो सकता है - ऐसे सिमुलेटरों के लगभग सभी (इकाइयों को छोड़कर) - गतिहीन हैं। हमने एक चल मंच पर सिम्युलेटर का निर्माण किया, और इसलिए लंबे केबल और कंपन समस्याओं की आवश्यकता पैदा हुई।

ठीक है, यदि ऐसा है, तो आप उससे कहीं भी नहीं मिल सकते हैं, जिसका अर्थ है कि आपको केबल को जितना संभव हो उतना छोटा करने की आवश्यकता है, यूएसबी को एक्सटेंशन केबल के माध्यम से 10 मीटर तक न खींचें, लेकिन कंप्यूटर को बोर्ड पर रखें। आगे देखना: इसका मतलब है कि डिस्क रहित कंप्यूटर बोर्ड पर होना चाहिए। यह एक अलग उत्कृष्ट कार्य है, जिसकी चर्चा मैं निम्नलिखित भागों में से एक में करूँगा।

यांत्रिक समस्याओं

कैब में गतिशीलता + लोग = यांत्रिकी के साथ विभिन्न समस्याएं।
थ्रेडेड कनेक्शन कंपन से खोलना, स्व-टैपिंग शिकंजा बाहर गिरते हैं, और समय के साथ, प्लास्टिक उखड़ना शुरू हो जाता है।
हमारे ग्राहक पेशेवर पायलट नहीं हैं, लेकिन आम लोग, कभी-कभी विमानन के बारे में बहुत उत्साही नहीं होते हैं। वे नहीं जानते कि क्या किया जा सकता है और क्या नहीं किया जा सकता है।
जीवन के प्रमुख में एक सामान्य औसत व्यक्ति, अनजाने में, एक वास्तविक विमान उपकरण से हैंडल को फाड़ सकता है, और इसे नोटिस भी नहीं कर सकता है। हालांकि, "वयस्क" प्रशिक्षण केंद्रों से हमारे साथी इंजीनियरों की कहानियों के अनुसार, असली पायलट कभी-कभी एक ही काम करते हैं।

नए सिम्युलेटर में, हमने प्रतिशत के इस रेक को 95% से जीत लिया: सभी केबलों को ठीक किया जाना चाहिए, सभी थ्रेडेड कनेक्शन बंद हैं। कोई पेंच नहीं। कपलर, कपलर, कपलर। शेष 5 प्रतिशत अभी भी हमारे ग्राहक हैं। काश, यहाँ - केवल एक स्नेही, लेकिन लगातार शब्द के साथ। यह मैं संगठनात्मक निष्कर्ष का संदर्भ देता हूं।

निष्कर्ष

योजना, डिजाइन, लिखना, सोचना, विश्लेषण करना।
"एक चादर से", आप शायद एक शाम में एक स्कूटर बना सकते हैं, लेकिन मांस की चक्की चली गई है। एक उड़ान सिम्युलेटर - और भी बहुत कुछ।
महत्वपूर्ण, भूमिका नहीं होने पर पिछली विफलताओं के विश्लेषण ने महत्वपूर्ण भूमिका निभाई। "सीखे गए पाठ" के व्यवस्थितकरण के लिए धन्यवाद, सोचने और पहले आकर्षित करने की आवश्यकता है, और फिर करने के लिए, स्पष्ट हो गया।

बेशक, पुरानी रेक के हिस्से से बचने के बाद, हमने नए लोगों को पाया, लेकिन छह महीने के अनुभव से पता चला कि नए सिम्युलेटर की परिचालन विश्वसनीयता बहुत अधिक है। बहुत कम डाउनटाइम, विफलताओं और विफलताओं। कई और अधिक खुश ग्राहक, और यह ठीक लक्ष्य है।

निम्नलिखित पदों में मैं विस्तार से ए 320 के निर्माण की प्रक्रिया का वर्णन करूंगा।

अद्यतन

मुझे बोइंग इमारत से तस्वीरें मिलीं, मैं इसे पोस्ट करता हूं।

हेल्स के साथ केबिन का आधार। प्रारंभ में, कंप्यूटर बिजली की आपूर्ति का उपयोग किया गया था, जो एक बड़ी बुराई बन गया। अब मीनवेल


इटली से एक मोबाइल प्लेटफॉर्म आया। सबसे मोबाइल प्लेटफॉर्म का द्रव्यमान लगभग 800 किलोग्राम है, नियंत्रण कैबिनेट एक और 800 है।


हमारे पास लोडर (एयरबेस के साथ - अब नहीं था, कोई जगह नहीं थी) का उपयोग करने का अवसर था। बाईं ओर सर्वर रैक का पहला संस्करण है। दाईं ओर धातु संरचनाएं हैं, जिस पर प्रोजेक्शन स्क्रीन खींची जाएगी।


कॉकपिट विधानसभा। एमआईपी (मेन इंस्ट्रूमेंट पैनल) लगभग असेंबल किया जाता है।


बेस और फ्रेम के साथ कॉकपिट।


खुली छत पैनल के लिए खिड़कियों के माध्यम से देखें। इसके बाद, यह स्पष्ट हो गया कि केबल बिछाने का चुना हुआ तरीका गलत था।


हमारे कनाडाई विशेषज्ञ इंटरफ़ेस सॉफ़्टवेयर को कॉन्फ़िगर करते हैं - FSUIPC और नियंत्रकों के बीच एक परत। प्रत्येक बटन-टॉगल-स्विच-लैंप-संकेतक एफएसयूआईपीसी चर के लिए "संलग्न" है। एक बार जब हमने इस कॉन्फ़िगरेशन को खो दिया - यह मजेदार था।


आधार की विधानसभा की शुरुआत जिस पर गैंगवे की सवारी होगी।


केबिन, प्लेटफॉर्म, प्लेटफॉर्म कंट्रोल कैबिनेट। नियंत्रण कैबिनेट का "दिल" सीमेंस पीएलसी है। ड्राइवर - बॉमुलर। इंजन के साथ ड्राइवर एक अलग लेख के लायक हैं। उदाहरण के लिए, अंदर चालक मोटर की लोडिंग के आधार पर मोटर वाइंडिंग के तापमान पर विचार करता है। इसके अलावा, वाइंडिंग में कई तापमान सेंसर होते हैं, जो निश्चित रूप से, नियंत्रक से भी जुड़े होते हैं। जो, हालांकि, उसे अलार्म जारी करने और सभी गतिशीलता को रोकने से रोकता नहीं है अगर गणना की गई तापमान अनुमेय सीमा से परे कूद गया है। और गणना इंजन के अनूठे मापदंडों पर आधारित है, जिन्हें कारखाने में परीक्षण के दौरान हटा दिया जाता है। जब हमें इस कठिनाई का सामना करना पड़ा (परिकलित तापमान के साथ), तो हमें संयंत्र के संपर्क में रहना पड़ा।


एक प्लेटफ़ॉर्म कंट्रोल कैबिनेट और सर्वर के साथ एक रैक जैसा कि वे 4 साल पहले थे।


और अब - rrraz, और हमने एक लोडर के साथ प्लेटफॉर्म पर कैब को फहराया।


ORE ब्लॉक (इंजन नियंत्रण की छड़ें, अंग्रेजी में थ्रोटल क्वाड्रेंट)। दरअसल, प्रोजेक्ट में मेरी उपस्थिति का कारण। यह बिल्कुल काम नहीं किया। ब्लॉक एक जर्मन शिल्पकार द्वारा बोइंग 737-300 के साथ एक वास्तविक ब्लॉक से बना है। दुर्भाग्य से, शिल्पकार ने ज्यादातर कोंडो बोइंग यांत्रिकी को फेंक दिया, और इसे हास्यास्पद कर्षण के साथ बदल दिया, और, कुछ स्थानों पर, (चुटकुलों के बिना) एक हल्की टोपी। और पेंच टर्मिनल ब्लॉक ने सोल्डर में भरने का फैसला किया। नियंत्रकों का इस्तेमाल किया - फ़िज़ेट्स। कुल मिलाकर इस यूनिट के लिए उनमें से 6 हैं।


यदि मुझे सही ढंग से याद है, तो यहां हम यह पता लगाने की कोशिश कर रहे हैं कि यूनिट के अंदर बिजली कैसे वितरित की जाती है (उनमें से दो - 12 और 5)। इस शक्ति का उपयोग मोटर्स (वाइपर से) को चलाने के लिए किया जाता है, जो ट्रैक्शन मशीन के संचालन का अनुकरण करते हैं जब हैंडल "अपने दम पर" यात्रा करते हैं।


कैब के आधार पर देखें। USB एक्सटेंशन डोरियों की संख्या पर ध्यान दें। ये पहले थे, उनके बाद अधिक थे, और अधिक, और अधिक। केबल तय नहीं हैं, यह विस्तार डोरियों की विफलता का एक कारण था।


हमने प्रोजेक्शन स्क्रीन को खींचा और छवि को कम किया। TrippleHead2Go का उपयोग एक छवि विभक्त के रूप में किया गया था, और एक बेलनाकार स्क्रीन के नीचे छवि विरूपण के लिए सॉफ्टवेयर के रूप में Sol7 का उपयोग किया गया था।


काम के क्षणों में से एक। यदि स्मृति कार्य करती है, तो हम इस विषय पर शपथ लेते हैं कि अयस्क को कैसे ठीक से बनाया जाए।


में चल रहा है।


2009 में कॉकपिट का अंतिम दृश्य।


जंगम मंच के संचालन के दौरान बाहरी दृश्य।

अद्यतन # 2

अभी, इस पोस्ट से बोइंग इस तरह दिखता है:

और भी बहुत कुछ

और इतना:


इस सब को "ओवरहाल" शब्द कहा जाता है।

अगर किसी के पास कल और शुक्रवार को हमारे धूल भरे सिम्युलेटर को चुनने के लिए समय और खुजली वाले हाथ हैं, तो मुझे पीएम में लिखें।