تصور کنید تفاوت میان رباتی که کورکورانه دستور «نوشیدنی بریز» را اجرا میکند و رباتی که ابتدا بررسی میکند آیا واقعاً لیوانی در جای خود هست یا خیر را در نظر بگیرید؛ اولی یک ریسک و منبع خسارت است، در حالی که دومی یک ابزار کاربردی است. در ۱۰ آگوست ۲۰۲۶، MyZubster با ادغام یک ماژول دوربین هوشمند (Smart Camera) قابل استفاده مجدد، این تحول را رقم زد و اکوسیستم رباتیک خود را از مدل «دستور-عمل» به معماری «ادراک-تصمیم-عمل» منتقل کرد.
بیشتر پروژههای رباتیک آماتوری یا متنباز بر پایه اسکریپتهای سخت و صلب میچرخند که در آنها ماشین فرض میکند محیط کاملاً بینقص و پیشبینیپذیر است. MyZubster تلاش میکند این الگو را با ایجاد یک لایه بینایی مشترک بشکند که هر رباتی در اکوسیستمش، فارغ از هدف و کاربرد خاصش، بتواند از آن استفاده کند. این اقدام را میتوان به مثابه دادنِ یک جفت چشم مشترک به ناوگان متنوعی از رباتها دانست تا توسعهدهندگان مجبور نباشند برای هر پروژه جدید، کدهای پایه بینایی کامپیوتر را از ابتدا بازنویسی کنند.
همانطور که در تحلیلهای پیشین ما درباره امنیت مدلهای بازمتن اشاره کردیم، استانداردسازی لایههای زیرساختی کلید مقیاسپذیری در پروژههای توزیعشده است. طبق گزارش فنی وبسایت dev.to، سیستم جدید MyZubster لایه بینایی را بهطور کامل از منطقِ عملیاتی هر ربات جدا کرده است. این ساختار ماژولار به دوربین هوشمند اجازه میدهد تا یک رابط (Interface) ثابت و سازگار برای وظایف مختلف هوش مصنوعی فراهم کند:
- OpenCV: برای پردازش کلی تصاویر و عملیات پایه بینایی
- YOLO: برای تشخیص اشیا (Object Detection) در زمان واقعی — شبیه به کسی که در یک ثانیه میتواند تمام میوههای موجود در یک سبد را شناسایی و نام ببرد.
- یکپارچهسازی سیستمهای تشخیص و شناسایی چهره (Face Detection and Recognition)
- پشتیبانی از ورودیهای مستقیم دوربین واقعی
- یک «حالت شبیهساز» (Mock Mode) تخصصی برای توسعهدهندگانی که به سختافزار فیزیکی دسترسی ندارند
این معماری به این معناست که هرگونه بهبود یا ارتقاء در پیادهسازی هسته YOLO بهطور خودکار به نفع تمام رباتهای موجود در ناوگان خواهد بود. جریان کاری اکنون از یک زنجیره ساده «کاربر $\rightarrow$ ربات $\rightarrow$ عمل» به یک خط لوله (Pipeline) پیچیده تبدیل شده است: «دوربین $\rightarrow$ بینایی کامپیوتر $\rightarrow$ تشخیص $\rightarrow$ تصمیم ربات $\rightarrow$ عمل فیزیکی».
از نظر فنی، این چارچوب بهگونهای طراحی شده است که پردازش خام بینایی را از برنامههای کاربردی خاص هر ربات ایزوله کند. لایه هسته دوربین هوشمند شامل OpenCV، YOLO، تشخیص/شناسایی چهره و هر دو ورودی دوربین واقعی و شبیهساز است. این جریان داده سپس به ماژولهای بینایی ربات (Robot Vision Modules) منتقل میشود که برای نقشهای مختلف سفارشی شدهاند:
- Fluffypony: متخصص در تشخیص لیوان (Glass Detection)
- Hera: متمرکز بر تشخیص انسان (Person Detection)
- Nurse: طراحی شده برای پایش و نظارت بر بیمار (Patient Monitoring)
- Industrial: ساخته شده برای ردیابی اشیا (Object Tracking)
- Educational: ایجاد سیستمهای بینایی تعاملی برای اهداف آموزشی
برای نمایش سادگی این یکپارچهسازی، سیستم از یک رابط پایتونی ساده استفاده میکند. یک توسعهدهنده میتواند تابع FluffyponyVision() را فراخوانی کرده و سپس متدهای vision.check_glass() و vision.detect_person() را اجرا کند. تنها در صورتی که هر دو متد مقدار True را برگردانند، ربات وضعیت «آماده برای سرویس» را فعال میکند. این جداسازی تضمین میکند که منطق اختصاصی ربات از پیادهسازی فنی بینایی کامپیوتر مجزا بماند و در نتیجه نگهداری کل سیستم بسیار آسانتر شود.
یکی از حیاتیترین بخشهای این سیستم، «حالت شبیهساز» (Mock Mode) است. از آنجایی که سختافزار واقعی همیشه در مراحل توسعه در دسترس نیست، MyZubster این حالت را پیاده کرد تا توسعهدهندگان بتوانند منطق تشخیص، جریانهای کاری ربات، یکپارچهسازی API، مدیریت خطاها و فرآیندهای تصمیمگیری را بدون نیاز به اتصال دوربین فیزیکی تست کنند.
در نتیجه، چرخه توسعه به این شکل تغییر یافته است: «دوربین شبیهساز $\rightarrow$ تست نرمافزاری $\rightarrow$ منطق ربات $\rightarrow$ تست یکپارچگی $\rightarrow$ دوربین واقعی $\rightarrow$ تست فیزیکی». این رویکرد سرعت توسعه را بهشدت افزایش داده و با شناسایی خطاهای منطقی پیش از روشن شدن و فعال شدن سختافزار، ایمنی عملیاتی را بالا میبرد.
در حال حاضر دو کاربرد اصلی از این قابلیت استفاده میکنند. ربات متصدی بار Fluffypony اکنون از بینایی برای تأیید حضور لیوان و شخص پیش از شروع سرویس استفاده میکند. جریان کاری از یک مسیر سختگیرانه پیروی میکند: «دوربین $\rightarrow$ فریم تصویر $\rightarrow$ تشخیص شیء $\rightarrow$ شناسایی "لیوان" $\rightarrow$ شناسایی شخص $\rightarrow$ ادامه سرویس توسط ربات».
به جای ریختن کورکورانه نوشیدنی، سیستم کلاسهای خاص اشیا را با «امتیاز اطمینان» (Confidence Score) بررسی میکند. برای مثال، ماژول بینایی ممکن است خروجی زیر را بدهد: «در حال بررسی لیوان... لیوان شناسایی شد، شخص شناسایی شد. آماده برای سرویس». در یک نتیجه پردازشی معمولی، ممکن است لیوان با اطمینان ۰.۸۷ و شخص با اطمینان ۰.۹۲ شناسایی شوند. تغییر کلیدی این است که اطلاعات بصری اکنون یک «ورودی» برای جریان کاری ربات است، نه یک ویژگی ثانویه.
به موازات این مورد، پروژه Hera Security Vision از دوربین برای تحلیل تصاویر در طول گشتهای امنیتی استفاده میکند. جریان کاری در اینجا سادهتر است: «دوربین $\rightarrow$ فریم $\rightarrow$ تشخیص شخص $\rightarrow$ تحلیل $\rightarrow$ رویداد $\rightarrow$ جریان کاری امنیتی». در یک تست توسعه، خروجی سیستم به این شکل بود: «در حال اسکن محیط... ۲ نفر شناسایی شدند. رویداد شناسایی شد» (EVENT DETECTED).
اگرچه Hera هنوز یک محصول امنیتی گواهیشده و تجاری نیست، اما این آزمایش ثابت کرد که خط لوله مذکور میتواند یک متجاوز را شناسایی کرده و دادههای مربوطه را به جریان کاری امنیتی منتقل کند. استقرار واقعی در آینده نیازماد تستهای تکمیلی، تدابیر حفاظتی حریم خصوصی، نظارت انسانی و مدیریت «مثبتهای کاذب» (False Positives) خواهد بود.
سیستم بینایی در خلاء عمل نمیکند و دادهها را به EVA میفرستد؛ یک عامل (Agent) هوشمند MyZubster که به عنوان لایه هماهنگی (Orchestration) عمل میکند. معماری تکاملیافته این مسیر را طی میکند: «دوربین $\rightarrow$ ماژول بینایی $\rightarrow$ تشخیص $\rightarrow$ درگاه (Gateway) $\rightarrow$ EVA/AI $\rightarrow$ تصمیم $\rightarrow$ ربات».
عامل EVA میتواند یک رویداد بینایی — مانند تشخیص یک نفوذگر — را دریافت کرده و وضعیت را برای یک اپراتور انسانی تلخیص کند، تا دیگر نیازی نباشد انسانها بهطور مداوم به تصاویر خام دوربین خیره شوند. در این مدل، هوش مصنوعی لایه تفسیر و هماهنگی است، در حالی که سیستم بینایی مسئول ادراک خالص محیط است.
این ساختار با یک مدل اقتصادی گستردهتر مبتنی بر ارز دیجیتال مونرو (XMR) گره خورده است. اکوسیستم بهگونهای طراحی شده که ادراک، هوش مصنوعی و پرداختها را به هم پیوند دهد. این رویکرد در واقع تکاملیافتهی سیستمی است که چگونگی تراکنشهای مستقل رباتها با استفاده از مونرو و x402 را ممکن میسازد. در یک استقرار کامل، معماری شامل این زنجیره است: «انسان، EVA، درگاه، بینایی، گیتهاب، تصمیم، ربات، عمل فیزیکی و پرداخت». در نهایت، یک ربات میتواند درخواستی برای سرویس دریافت کند، پرداخت را با XMR تأیید نماید، با استفاده از حسگرها محیط را درک کند، تصمیم بگیرد، عمل را انجام دهد و نتیجه را گزارش کند.
تمام این پیشرفتها از طریق سیستم «جایزه» (Bounty) در گیتهاب تأمین و اجرا شده است. توسعه بر اساس نقشهراههای مبهم شرکتی نیست، بلکه روی «ایشوهای» (Issues) مشخص و پرداختشده متمرکز است. این مدل توسعه، تداومبخشِ استراتژی MyZubster است که با ترکیب Ollama و Monero، اتوماسیون پاداشهای متنباز را بهصورت محلی پیاده کرد. مشارکتکنندگان یک ایشو را برمیدارند، کد را پیاده میکنند، درخواست Pull Request میدهند و پس از ادغام (Merge) شدن کد، جایزه XMR دریافت میکنند.
آثار تکمیلشده اخیر که در مجموع ۳۵ XMR هزینه شده است، عبارتند از:
- یکپارچهسازی سختافزاری (Issue #84): ۵ XMR
- مانیتور (#89): ۴ XMR
- دستیار (#64): ۴ XMR
- گشت امنیتی (#83): ۳ XMR
- ربات امنیتی (#66): ۳ XMR
- رابط وب (#87): ۳ XMR
- ربات نظافتچی (#61): ۳ XMR
- جلوههای صوتی (#86): ۲ XMR
- باغبان (#62): ۲ XMR
- زمانبند (#63): ۱ XMR
نقشه راه MyZubster برای استقرار قابلیتهای بینایی در بخشهای مختلف به شرح زیر است:
- Fluffypony: تشخیص لیوان (پیادهسازی شد ✅)
- Hera: تشخیص انسان (پیادهسازی شد ✅)
- Nurse: پایش بیمار (در حال توسعه ⏳)
- Industrial: ردیابی اشیا (برنامهریزی شده ⏳)
- Educational: بینایی تعاملی (برنامهریزی شده ⏳)
نقطه عطف و تست نهایی در سپتامبر ۲۰۲۶ و در رویداد TAZ DAY #1 در شهر ریچونه ایتالیا رخ خواهد داشت. در این مراسم، نرمافزارها از فضای شبیهساز به دنیای واقعی منتقل میشوند تا تعامل بین AI، حسگرها و انسانها در یک محیط فیزیکی تست شود. نمایشهای برنامهریزی شده شامل سرویس متصدی بار Fluffypony با کمک بینایی، کانسپت بینایی امنیتی Hera، کانسپت ربات نظافتچی خودکار Hera و ربات باغبانی Hera برای مراقبت از گیاهان است.
البته افزودن دوربین به رباتهای متنباز ریسکهای جدی حریم خصوصی را به همراه دارد. پروژه اشاره میکند که یک سیستم آماده تولید باید مواردی چون رضایت کاربر، کمینهسازی دادهها (Data Minimization)، ذخیرهسازی امن، کنترل دسترسی، سیاستهای نگهداری داده و رمزنگاری را در نظر بگیرد. بر پردازش محلی (Local Processing) تأکید شده است تا اطمینان حاصل شود که بینایی کامپیوتر بهطور خودکار به نظارت دائمی تبدیل نمیشود.
هدف، ایجاد اکوسیستم متمرکز بر حریم خصوصی است که در آن دادههای بصری صرفاً به عنوان یک «محرک گذرا» برای انجام یک عمل تلقی شوند، نه یک رکورد دائمی. این موضوع بهویژه زمانی که سیستمها در محیطهای عمومی یا خصوصی در اطراف افراد واقعی فعالیت میکنند، حیاتی است.
انتقال از رباتهایی که صرفاً «اجرا» میکنند به رباتهایی که «ادراک» دارند، ماهیت پروژه MyZubster را بنیادین تغییر داد. با این کار، پروژه در حال ساخت زیربنای لازم برای رباتیک واقعاً خودکار است. اکنون چرخه توسعه به یک حلقه کامل تبدیل شده است: «کد $\rightarrow$ شبیهساز $\rightarrow$ تست واحد $\rightarrow$ یکپارچگی $\rightarrow$ دوربین واقعی $\rightarrow$ ربات $\rightarrow$ محیط واقعی $\rightarrow$ مشاهده $\rightarrow$ ثبت ایشو $\rightarrow$ جایزه $\rightarrow$ اصلاح $\rightarrow$ تست مجدد».
هر تست در دنیای واقعی، مانند رویداد ریچونه، میتواند مشکلات جدید را آشکار کند. هر مشکل به یک ایشوی گیتهاب تبدیل میشود و هر ایشو فرصتی برای مشارکت متنباز از طریق جوایز XMR است. این روند، یک حلقه خودبهبودبخش از تکامل نرمافزاری و سختافزاری فیزیکی ایجاد میکند.
گام بعدی شما
- اگر توسعهدهنده رباتیک هستید، معماری جداسازی لایه ادراک (Perception) از لایه تصمیم (Decision) را در پروژههای خود تست کنید.
- برای کاهش هزینههای سختافزاری در مراحل اولیه، یک لایه Mock Camera مشابه MyZubster برای تست منطق نرمافزاری بسازید.
- بررسی کنید چگونه مدلهای تشخیص اشیا مثل YOLO میتوانند به جای جایگزینی انسان، به عنوان لایه تأیید (Verification) در جریانهای کاری عمل کنند.
اما چالش اصلی در دنیای واقعی، مدیریت تأخیر در استنتاج لبهای است — به تحلیل ما درباره محاسبات در لبه (Edge Computing) مراجعه کنید.
گفتگو