با انتخاب سیستم عامل مناسب می‌توان عملکرد سامانه‌های رباتیک را به طور قابل توجهی بهبود بخشید. در ادامه تأثیر سیستم‌های ‌عامل در طراحی و توسعه ربات‌ها را بررسی می‌کنیم. همچنین اهمیت معیار زمان تأخیر، ویژگی‌ها و روش‌های اندازه‌گیری آن که بیشتر مواقع درنظر گرفته نمی‌شود و یا به اشتباه اندازه‌گیری می‌شود را بررسی خواهیم کرد.

تأخیر یک نگرانی مهم عملی در جهان رباتیک است که اغلب به خوبی درک نمی‌شود. احساس می‌کنم که درک بهتر از تأخیر می‌تواند به پژوهشگران و مهندسان رباتیک کمک کند تا طراحی و معماری تا حد زیادی ساده ایجاد کنند و به روند تحقیق و توسعه سرعت ببخشند. من شخصاً ساعت‌های بسیاری را صرف جمع‌آوری و جست‌وجوی اطلاعات در مورد ویژگی‌های زمان تأخیر اجزای مختلف رباتیک کردم اما به سختی می‌توان اطلاعاتی قوی که به وضوح ارائه و یا حمایت شده را پیدا کرد. چیزی که من فهمیدم، بیشترین تمرکز روی حدأکثر توان است و موضوع تأخیر نادیده گرفته شده و یا به اشتباه اندازه‌گیریمی‌شود.

در ادامه دو موضوع اصلی را پوشش خواهیم داد:

• جزئیات در مورد چگونگی اندازه‌گیری معیارهای تأخیر
• سیستم عاملی که برای بررسی تأثیر تأخیر استفاده می‌شود

در طول دوره چند ساله‌ی انجام پژوهش‌های رباتیک، ما بر این باوریم که پژوهش‌های رباتیک می‌تواند تسریع یابد؛ با طراحی سیستم‌هایی که ملزومات سختگیر زمان واقعی روی نرم‌افزارهایی که در معرض نمایش کاربر قرار می‌گیرد، را کاهش دهد. یک روش، پیاده سازی کنترل سطح پایین (کنترل موتور و ویژگی‌های ایمنی) در اجزای اختصاصی است که از کنترل سطح بالا (موقعیت، سرعت، گشتاور و غیره) مستقل است. در بسیاری از موارد این کار می‌تواند کاربران را قادر به اعمال نفوذ روی ابزار سخت افزار و نرم افزار مشترک مصرف کننده کند و از این طریق توسعه را تسریع ببخشد.

به عنوان مثال آزمایشگاه Biorobotics در کارنگی‌ملون پژوهشگرانی دارد که بیشتر تمایل دارند مهندس مکانیک یا الکترونیک باشند تا دانشمند رایانه و یا مهندس نرم افزار. به این ترتیب تمایل آنها به آشنایی با لینوکس و C/C ++ کمتر است و خیلی راحت‌تر با سیستم عامل Windows/mac و زبان‌های برنامه‌نویسی مانند MATLAB کنار می‌آیند. سپس آزمایشگاه شروع به فراهم آوردن پشتیبانی کراس پلت‌فرم (چندسکویی) و پوشش MATLAB کرد و افزایش قابل توجهی در خروجی پژوهش‌ها مشاهده کرد. تقریباً مقالات منتشر شده آزمایشگاه درمورد ربات مار دو برابر شده بود. به طور ویژه آزمایشگاه قادر به توسعه و نمایش رفتارهای جدید پیچیده‌ای بود که نمونه قبلی به سختی آنها را پشت سر می‌گذاشت.

اندازه‌گیری تأخیر

ربات‌ها در زمان واقعی کنترل می‌شوند، به این معنی که یک فرمان در یک مهلت معین (دوره زمانی ثابت) اجرا می‌شود. سیستم‌های سخت زمان واقعی وجود دارد که هرگز نباید از مهلت خود تجاوز کنند و سیستم‌های نرم زمان واقعی که می‌توانند گاهی از مهلت خود تجاوز کنند. مهلت‌های از دست رفته هنگام انجام کنترل حرکتی یک ربات می‌تواند منجر به حرکات ناخواسته و رفتار تشنجی شود.

اگر چه اطلاعات بسیاری در مورد تعریف نظری این شرایط وجود دارد اما می‌توان تعیین حدأکثر مهلت (نقطه‌ای که در آن عملکرد یک سیستم شروع به تنزل و یا ناامن می‌شود) برای کاربردهای عملی را به چالش کشید. این امر به ویژه برای مؤسسات پژوهشی که مکانیزم‌های جدید و کاربردهای پیشرفته را ایجاد می‌کنند، صادق است. بسیاری از گروه‌های پژوهشی این فرض که همه چیز نیاز به زمان واقعی سخت با ضرب العجل بسیار دقیق دارد را رد می‌کنند. در حالی که این رویکرد عملکردی قابل اطمینان را ضمانت می‌کند از طرفی نیز می‌تواند موجب توسعه‌های غیرضروری شود.

بسیاری از معیارها و ابزارها با این فرض ایجاد می‌شوند که زمان تأخیر یک توزیع گوسی دارد و تنها میانگین و انحراف استاندارد را گزارش می‌کنند. متأسفانه زمان تأخیر تمایل به توزیع چند مدی دارد و مهم‌ترین بخش توزیع زمانی است که داده‌ها پرت هستند. حتی اگر زمان تأخیر یک سیستم رفتاری باشد که در ۹۹٪ از موارد انتظار می‌رود، ۱٪ باقی مانده می‌تواند بدتر از همه ۹۹٪ دیگر اندازه‌گیری‌ها باشد.  میانگین و انحراف استاندارد به تنهایی در مسائل سیستمیک شکست خورده است. برای نمونه من بسیاری از مجموعه داده‌ها را دیده‌ام که در آن فاصله انحراف استاندارد از میانگین بیشتر از ۱۰۰۰ بوده است. چنین اشکالاتی هنگام کار با سیستم‌های رباتیک واقعی معمولاً مشکل اصلی است.

به همین دلیل یک راه مناسب‌تر برای بررسی تأخیر از طریق نمودارهای هیستوگرام و درصدی است، برای نمونه «۹۹٫۹٪ از اندازه‌گیری‌ها زیر  Xمیلی ثانیه بودند». چندین منبع خوب در مورد ثبت زمان تأخیر وجود دارد که من توصیه می‌کنم، مانند چگونه زمان تأخیر را اندازه‌گیری نکنیم و یا HdrHistogram: یک روش ثبت تأخیر.

سیستم‌های عامل

سیستم عامل، اساس هر چیزی است. مهم نیست که نرم افزار سطح بالا چه عملکردی دارد، اساساً عملکرد سیستم محدود به قابلیت‌های سیستم عامل، زمانبندی آن و بار کلی روی سیستم است. قبل از اینکه شروع به بهینه‌سازی نرم افزار خود کنید باید مطمئن شوید که هدفتان بر روی پلت‌فرم‌های زمینه دست‌یافتنی است.

همیشه بین زمان، عملکرد کلی، عمر باتری و همچنین چندین مورد دیگر یک بده‌بستان وجود دارد. به این دلیل بیشتر سیستم عامل‌های مصرف کننده تضمین نمی‌کنند که بین تأخیری که به لحاظ تئوری محاسبه شده و مکث عملی فاصله‌ای وجود نداشته باشد.

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

توسعه سیستم‌های سخت زمان واقعی مشکلات بسیاری دارد و توسعه آنها نیز به تلاش زیادی نیاز دارد و لازم است پژوهشگران کدهای سازگار به زمان واقعی بنویسند، اما این چیزی نیست که آنرا توصیه کنم.

نتیجه

ما تجربه بسیار خوبی با اجرای کنترل سطح پایین (حلقه‌های PID، کنترل موتور، ویژگی‌های ایمنی و غیره) در سطح هر محرک داشته‌ایم. به این ترتیب که همه قطعات حساس به تأخیر و ایمنی توسط یک RTOS (سیستم عامل زمان واقعی) اختصاصی به کار گرفته و مستقل از کد کاربر می‌باشد.  پس از آن کنترلرهای سطح بالا تنها نیاز به  به‌روز‌رسانی اهداف مجموعه (به عنوان مثال موقعیت / سرعت / گشتاور) دارد که به مراتب کمتر به تأخیر حساس است و نیازی به ارتباطات سخت زمان واقعی ندارند. این رویکرد نمونه‌سازی سریع از رفتارهای سطح بالا با استفاده از فناوری غیر معین مانند ویندوز، MATLAB و پیام‌های UDP استاندارد را ممکن می‌سازد.

برای نمونه کنترل سطح بالا در Teleop Taxi با Wi-Fi و MATLAB بر روی ویندوز انجام شده، در حالی که به طور همزمان ویدئو از یک تلفن آندروید در پشت ربات دریافت می‌شود. با از بین بردن نیاز به یک رایانه محلی، تنها ۲۰تا۳۰ خط کد برای اجرای کل نسخه‌ی نمایشی نیاز دارد. در واقع استفاده از یک رایانه محلی هیچ مزیتی ندارد. در حالی که هر سیستمی را نمی‌توان به طور کامل از طریق Wi-Fi کنترل کرد، ما نتایج مشابهی حتی با سیستم‌های پیچیده‌تر دیده‌ایم.

توزیع زمان تأخیر گوسی نیست

در نهایت دوباره تأکید می‌کنم که زمان تأخیر عملاً هرگز یک توزیع گوسی ندارد. برای نمونه در سیستم OSX بیشترین مقدار بیش از ۴۰۰ برابر انحراف استاندارد از میانگین فاصله دارد. فهرست این مجموعه داده‌ها به شرح زیر می‌باشد.

شکل زیر توزیع واقعی داده‌ها برای ویندوز را با یک توزیع نظری گوسی مقایسه می‌کند. به جای یک منحنی زنگی کلاسیک، چندین خوشه جدا از هم در فواصل منظم را نشان می‌دهد. فاصله بین این خوشه‌ها تقریباً یک میلی ثانیه است که با وقفه ویندوز در حال جمع آوری اطلاعات مطابقت دارد.

مقایسه توزیع واقعی و توزیع گوسی (ویندوز)

با استفاده تنها از میانگین و انحراف استاندارد برای هر نوع مقایسه‌ی زمان تأخیر، نتایج فریبنده‌ای به دست می‌آورید. گذشته از گرفتن اطلاعات کم، در بسیاری از موارد که در آن سیستم‌ها به ظاهر عملکرد بهتری دارند در واقعیت بدترین عملکرد را داشته‌اند.

منبع: robohub.org