آشنایی با معماری سیستم کنترل ربات صنعتی

این مقاله به مقایسه راه حل های سیستم کنترل دو ربات صنعتی دستکاری و ربات متحرک پرداخته و ویژگی های آنها را معرفی می کند.

طبقه بندی فوق بر اساس شی برنامه است. علاوه بر این، کنترل کننده های حرکتی عمومی تری در بازار وجود دارد، یعنی آنهایی که تجهیزات غیر استاندارد را کنترل می کنند.

1 کنترلر سطح پایین راه حل 1.1 Manipulator نوع کنترل کننده نوع دستگیره را که قبلاً توسعه یافته و نسبتاً بالغ است ، نوع. بیایید نگاهی به راه حل سطح پایین سیستم کنترل موجود بیندازیم. 1.2 ربات موبایل نوع کنترلر ربات موبایل متعلق به یک جهت نسبتاً جدید است. روبات های موبایل صنعتی به صورت AGV ، ماشین آلات مهندسی بدون سرنشین و غیره هستند. راه حل سطح پایین سیستم کنترل به شرح زیر است:
1.3 مقایسه
Manipulator برای دقت و پایداری حرکت نیازهای بالایی دارد ، بنابراین مقدار محاسبه زیاد است و چرخه کوتاه است ، که به طور کلی 1 تا 2 مرتبه بیشتر از روبات های تلفن همراه است. ربات های تلفن همراه به طور کلی نیازهای زیادی برای دقت هماهنگ سازی ندارند و پیکربندی آنها نسبتاً کم است.
Manipulator به طور کلی در یک منطقه ثابت کار می کند و کنترلر آن معمولاً در شاسی قرار می گیرد ، بنابراین سطح حفاظت زیاد نیست ، به طور کلی IP20. روبات های تلفن همراه باید ضد آب و ضد گرد و غبار باشند زیرا باید به طور مکرر حرکت کنند ، به خصوص ماشین آلات مهندسی در فضای باز ، بنابراین باید ضد آب و ضد گرد و غبار را در نظر بگیرند. سطح حفاظت آنها بالاتر است ، به طور کلی IP67.

2 مقدمه ای بر CoDeSys 2.1 ترکیب CoDeSys
متوجه خواهید شد که بسیاری از نرم افزارهای کنترل ربات با کمک CoDeSys پیاده سازی می شوند، پس CoDeSys چیست؟
CoDeSys یک نرم افزار توسعه نرم افزاری PLC است. به بیان ساده، از دو بخش تشکیل شده است: سیستم توسعه و سیستم زمان اجرا. توسعه سیستم رابط نرم افزاری است که برای برنامه نویسی استفاده می شود (درست مانند ویژوال استودیو، اکلیپس و نرم افزارهای دیگر که می توان آنها را IDE نیز نامید). طراحی، اشکال‌زدایی و کامپایل برنامه‌های PLC همگی در IDE انجام می‌شوند، بخشی که کاربران اغلب با آن سروکار دارند.
پس از نوشتن برنامه PLC ، برای بهره برداری باید به دستگاه سخت افزار منتقل شود. با این حال ، برنامه PLC تولید شده در حال حاضر نمی تواند به خودی خود اجرا شود. این باید در یک محیط نرم افزاری خاص کار کند. این محیط سیستم زمان اجرا است که برای کاربران نامرئی است.
مکانهای نصب این دو معمولاً متفاوت هستند. IDE به طور کلی روی رایانه توسعه نصب می شود و سیستم زمان اجرا در دستگاه سخت افزاری قرار دارد که نقش کنترل دارد. این دو به طور کلی توسط کابل های شبکه متصل می شوند و این برنامه از طریق کابل شبکه برای بهره برداری به زمان اجرا بارگیری می شود.
Codesys در چین مشهور نیست ، اما در اروپا به ویژه در زمینه کنترل صنعتی شهرت دیرینه ای دارد. بسیاری از شرکت های ربات که در بالا به آنها اشاره کردیم از محصولات آن استفاده می کنند ، مانند Keba ، Beckheff ، Googol و تقریباً همه تولید کنندگان کنترل کننده ربات موبایل.
3S، شرکتی که CoDeSys را طراحی کرده است، فقط نرم افزار می فروشد، نه سخت افزار. مدار سخت افزاری باید توسط کاربر طراحی شود و 3S وظیفه انتقال Runtime System به سخت افزار مشتری را بر عهده دارد. Runtime System می تواند به صورت برهنه روی سخت افزار اجرا شود، اما معمولاً روی سیستم عامل اجرا می شود و پیکربندی سیستم عامل نیز وظیفه مشتری است.
اگر مشتری نیاز داشته باشد، IDE CoDeSys را می توان برای تغییر لوگو و ظاهر مشتری سفارشی کرد، به همین دلیل است که خواهید دید که پلتفرم های توسعه سازندگان مختلف متفاوت به نظر می رسند، اما سبک ها نسبتا مشابه هستند.
البته کاربران می توانند از IDE های دیگر نیز استفاده کنند. به عنوان مثال، Beckhoff از Visual Studio مایکروسافت استفاده می کند، در حالی که هسته و کتابخانه تابع پشت کامپایلر هنوز از راه حل CoDeSys استفاده می کند.
Runtime of CoDeSys سازگاری قوی دارد و از اکثر سیستم عامل ها و معماری تراشه های سخت افزاری پشتیبانی می کند.

2.2 اصل زمان اجرا CoDeSys
بخش IDE از Codesys رایگان است و می توانید آن را از وب سایت رسمی آن بارگیری کنید تا آن را تجربه کنید. شارژ واقعی سیستم زمان اجرا سیستم اجرا است.
در ابتدای طراحی، CoDeSys توابع را به چندین ماژول جزء تقسیم کرد، مانند پشته پروتکل اتوبوس، رابط بصری، کنترل حرکت، کنترل ایمنی و غیره. کاربران می توانند ماژول های لازم را برای ساختن سیستم خود مانند بلوک های ساختمانی انتخاب کنند و در نهایت یک پلت فرم نرم افزار کنترل سفارشی را تشکیل دهید.

ممکن است برخی از کاربرانی که به تازگی با Soft PLC آشنا هستند احساس ناآشنا بودن با این قسمت کنند، اما در واقع این روش طراحی بسیار رایج است. به عنوان مثال جعبه ابزار بلادرنگ (Real-Time) متلب سیمولینک به این صورت عمل می کند. کاربران برنامه های کنترلی را با کشیدن و رها کردن در رابط گرافیکی سیمولینک طراحی می کنند و سپس آنها را برای اجرا روی سخت افزار واقعی دانلود می کنند. در اینجا می توانید در مورد آن بیاموزید.
چنین روشی مانند Beckhoff نیز وجود دارد. کاربران در TwinCAT IDE برنامه ریزی می کنند و سپس آنها را در کنترلر Beckhoff دانلود می کنند. در واقع یک Runtime از قبل در کنترلر نصب شده است. زیمنس STEP7 نیز یک IDE است و PLC آن نیز دارای زمان اجرا مشابه است.
برنامه PLC نوشته شده توسط کاربر مانند برنامه در رایانه ما است. بر روی سیستم زمان اجرا و سیستم زمان اجرا بر روی سیستم عامل اجرا می شود.
سیستم زمان اجرا بین برنامه و سیستم عامل قرار دارد. بنابراین می توان آن را میان افزار نامید. در نرم افزار ربات، ROS، OROCOS (Real-Time Toolkit) و ... در یک موقعیت قرار دارند.
کنترل ربات ، مانند دستگاه های CNC ، به عملکرد زمان واقعی نیاز دارد ، بنابراین سیستم عامل مورد نظر ما ترجیحاً یک سیستم عامل در زمان واقعی (RTOS) است. متأسفانه ، سیستم عامل هایی که اغلب از آنها استفاده می کنیم ، در زمان واقعی نیستند ، مانند ویندوز و لینوکس. اما خوشبختانه ، کسی آنها را اصلاح کرده است ، یعنی تکه های زمان واقعی اضافه شده است.
سیستم عامل های زمان واقعی که معمولاً مورد استفاده قرار می گیرند عبارتند از: VXWORKS ، QNX ، ویندوز RTX ، Xenomai ، RT Linux ، Linux RTAI ، Wince ، μC/OS ، Sylixos و غیره. یک پچ مربوطه در زمان واقعی (RTE) برای نجات کاربران مشکل اصلاح.
برای کسب اطلاعات بیشتر در مورد زمان اجرا Codesys ، می توانید سند رسمی [خطای پردازش ریاضی] [1] [2] [1] [2] را بخوانید.
2.3 مضرات کدها

Codesys راحتی را برای توسعه کنترلر ما به ارمغان می آورد و مشکل شروع از ابتدا را برای ما نجات می دهد. با این حال ، همچنین در توسعه محصولات کنترلر خود بر اساس نرم افزارهای تجاری مانند کدها ، مضرات زیادی وجود دارد:
(1) الگوریتم اساسی باز نیست
اجزای کنترل حرکت و پشته‌های پروتکل گذرگاهی که توسط CoDeSys یکپارچه شده‌اند، همگی کپسوله شده‌اند. کاربران نمی توانند جزئیات داخلی خود را درک کنند و نمی توانند آنها را مطابق با نیازهای خاص خود سفارشی و بهینه کنند. آنها فقط می توانند آنها را به سادگی صدا کنند. کاربران فقط می توانند به پلتفرم CoDeSys تکیه کنند و برای ایجاد فناوری اصلی خود مشکل دارند.
(2) توابع محدود و گسترش آن دشوار است
فن‌آوری‌های جدید که توسط بینایی ماشین، هوش مصنوعی و رانندگی خودران نشان داده می‌شوند، اکنون با سرعتی جهشی در حال پیشرفت هستند، در حالی که بسیاری از فناوری‌ها در کنترل صنعتی هنوز 20 سال از عمرشان می‌گذرد. با در نظر گرفتن صحنه ناوبری در یک ربات متحرک به عنوان مثال، روش ناوبری مبتنی بر بینایی یا لیزر نیاز به جمع آوری مقدار زیادی داده و پردازش آن دارد که شامل محاسبات ماتریسی زیادی است.
اکنون PLC فقط می تواند محاسبات دیجیتالی یک بعدی به عقب را انجام دهد و اجرای الگوریتم های پیچیده را دشوار می کند. برخلاف سبک منبع باز جامعه هوش مصنوعی ، جامعه کنترل صنعتی برای یکدیگر بسته است. هیچ کس حاضر نیست کتابخانه های عملکرد خود را باز کند. کتابخانه های عملکرد منبع باز بسیار کمی (OSCAT) وجود دارد. حتی اساسی ترین الگوریتم های فیلتر و محاسبات ماتریس باید از ابتدا نوشته شود. علاوه بر این ، کارکردهای اساسی ارائه شده توسط استانداردهای بین المللی بسیار محدود هستند و به هیچ وجه نمی توانند با سناریوهای جدید سازگار شوند. آنها نیاز فوری به گسترش دارند.
(3) به روزرسانی دشوار است
با توجه به اعتماد کامل به کدها ، به روزرسانی سخت افزار محصول خود مشتریان باید سفارشی و پیوند شود و در نتیجه افزایش هزینه ها باشد.
3 راه حل منبع باز
در حال حاضر ، برخی از راه حل های سیستم کنترل منبع باز مانند Beremiz ، Orocos ، OpenPLC ، OpenRTM و ORCA وجود دارد.
توسعه کنترلرهای روبات کار سنگینی است. یک سری الزامات عملکرد باید روشن شود که اولین مورد آن عملکرد بلادرنگ است.
عملکرد بلادرنگ معمولاً برای روبات‌های صنعتی ضروری است، اما لزوماً برای ربات‌های خدماتی یا سرگرمی لازم نیست. برای مردم عادی آسان است که «عملکرد بلادرنگ» را با پردازش سریع یا سرعت پاسخ اشتباه بگیرند، اما در واقع «عملکرد بلادرنگ» به معنای «جبرگرایی» در زمان است. به عنوان مثال، زمان تأخیر پاسخ وقفه یا تغییر فرآیند در سیستم عامل بلادرنگ (RTOS) باید در محدوده زمانی باشد.
سیستم عامل هایی که ما معمولاً از آنها استفاده می کنیم (ویندوز ، لینوکس) سیستم عامل در زمان واقعی نیستند ، زیرا آنها برای توان طراحی شده اند و نمی توانند تضمین کنند که هر رویدادی در یک محدوده خاص پردازش می شود. به عنوان مثال ، سرعت انتقال اترنت استاندارد بسیار سریعتر از اترنت صنعتی در زمان واقعی است ، اما در زمان واقعی هم نیست ، زیرا همچنین نمی تواند تضمین کند که داده ها در یک زمان معین منتقل می شوند.
درک زمان واقعی دشوار نیست ، اما کدام وظایف ربات باید در زمان واقعی اجرا شود؟ چگونه می توان فاصله زمانی برنامه را با توجه به نیازهای عملکرد ربات (1ms یا 10ms) تعیین کرد؟ آیا زمان واقعی به سخت افزار یا نرم افزار بستگی دارد؟
چگونه سخت افزار و نرم افزار خاصی را بر اساس زمان واقعی (ARM یا X{1}}، Linux RTAI یا VxWorks) انتخاب کنیم؟ بحث عمیقی در مورد این جنبه در اینترنت وجود ندارد و سازندگان بزرگ ربات نتایج آزمایش و آزمایش خود را فاش نخواهند کرد. به نظر می رسد که این جنبه عمدتاً متکی به تجربه و آزمون و خطا است.
در اینجا فقط می توانم چند شاخص ارائه دهم. در حال حاضر، چرخه کنترل بازوهای ربات صنعتی حدود 1 میلی ثانیه است و چرخه کنترل حلقه موقعیت یک درایو سروو با عملکرد بالا می تواند به 125 [خطای پردازش ریاضی] mu sμs برسد. PLCopen استانداردهایی را برای کنترل سروو و حرکت تعریف می کند، از جمله زبان برنامه نویسی، بلوک های عملکرد اصلی کنترل حرکت، پارامترهای رابط های ورودی و خروجی، و غیره. [خطای پردازش ریاضی] ^{[3]}
[3] جزئیات کد اجرای خاص توسط تولید کنندگان مختلف ارائه شده است.