#Hardware

عادت دارم مراحل کار با سخت‌افزار و نرم‌افزار یک سیستم رباتیک را مستند کنم تا خودم و افراد تیم در آینده کار تکراری انجام ندهیم.

قبلا سنسور RealSense D455 را روی یک دسکتاپ و Ubuntu 20 برای تست الگوریتم راه‌اندازی کرده بودم. درایور آن و لانچ‌ فایل‌ها و مراحل نصب و اجرا را مستند کرده بودم تا امروز که یک ماه قبل پیش‌بینی کرده بودم بر روی Jetson Orin NX سریع همان مراحل را اجرا کنم. میان راه دیدم مشکل دارم.

بله، کامپیوتر دسکتاپ معماری پردازنده AMD داشت و Jetson معماری ARM دارد. هر چه بافته بودم پنبه شد. درگیر طی کردن همان مراحل برای ARM ها شدم که شب شد و ذهن آشفته و رها کردم برای فردا، از ریخت خطاها مشخص بود دقت لازم است که دیگر حوصله آن را نداشتم.

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

----------
@roboticknowledge

#ROS #RL #NN

پیاده‌سازی (deployment) یک شبکه عصبی در یک ROS Node با ++C

من از کتابخانه PyTorch برای آموزش مدل‌های عصبی که در Autonomy Stack ربات‌هایم نقشی دارند استفاده می‌کنم. مدل را می‌توان بصورت یک torch script با پسوند pt. ذخیره کرد. سپس این مدل را می‌توان با کتابخانه libtorch که یک کتابخانه ++C برای torch است را در محیط مبتنی بر ++C/C خواند و اجرا کرد.

کتابخانه libtorch می‌تواند بر روی CUDA بصورت accelerated مدل‌ها را اجرا کند. برای اینکه در یک ROS Node از جنس ++C این کار را بکنید، فقط لازم است تا CMakeLists آن ROS Package را به گونه‌ای تغییر دهید تا از محل کتابخانه libtorch و cuda_toolkit شما آگاه باشد و در سورس ROS Node از جنس ++C هم torch/torch.h را include کنید تا به توابع آن دسترسی داشته باشید.

به این ترتیب می‌توان مدل‌های PyTorch را در شرایط deployment و در اکوسیستم ROS با زبان ++C استفاده کرد. انجام Unit test را فراموش نکنید تا مطمئن شوید مدل به درستی کار می‌کند.

راهنمای خوب:
https://docs.pytorch.org/tutorials/advanced/cpp_export.html

----------
@roboticknowledge

#Meme
وقتی که بهتر است ربات نداند چه کاربری دارد! 😂

----------
@roboticknowledge

#Tools

گاهی اوقات لازم است تا دوران‌ها را بررسی کنیم تا اطمینان پیدا کنیم ار برخی تبدیل‌ها. این وبسایت برای این چک‌ها خیلی خوب است:
https://www.andre-gaschler.com/rotationconverter/
مثلا دیتای nav_msgs/Odometry جهت‌گیری را با quaternion فرستاده است و شما می‌خواهید سریع roll-pitch-yaw را بررسی کنید. این ابزار اینجا به کار می‌آید!

—————
@roboticknowledge

#ROS #Tools

زوایای دوران را در بسیاری از مواقع دوست داریم به بازه [pi pi-] انتقال دهیم. چرا؟ ما میدانیم که زاویه 380 درجه برابر با زاویه 20 درجه است و با این تبدیل همواره زوایای جهت‌گیری را در محدوده [pi pi-] نگه می‌داریم. مهم‌ترین مکان برای این تبدیل در بحث یادگیری ماشین است که تلاش می‌شود ورودی‌های شبکه بصورت normalized بشوند تا یادگیری آسان‌تر بشود.

به این تبدیل ssa یا smallest signed angle گفته می‌شود. فرمول ریاضی این تبدیل بصورت زیر است:

signed reminder((angle + pi), 2pi) - pi

در ROS یک کتابخانه وجود دارد به نام angles که این را پیاده‌سازی کرده‌اند و شما می‌توانید این تبدیل را براحتی انجام دهید:

static double angles::normalize_angle (double angle)

می‌توانید داکیومنت همه توابع این کتابخانه را اینجا ببینید:
https://docs.ros.org/en/jade/api/angles/html/angles_8h.html

—————
@roboticknowledge

#Planning

کمی در حال مطالعه درباره ماژول‌های safety در ربات‌های خودران بودم و مفاهیم جالبی را متوجه شدم. اساس مباحث safery و سطح آن خروجی یک ماژول است که Collision Check and Prediction نام دارد. گارانتی ایمنی (در سطوح مختلف) در برابر تصادف بر اساس عملکرد و طراحی این ماژول تعیین می‌شود. با این که تنها یک ماژول در Autonomy Stack یک ربات مدرن است، اما دنیایی دارد و ریاضیات آن نیز از ساده تا پیچیده را در بر می‌گیرد. از بررسی‌های ساده هندسی تا PDE‌ها و آمار و احتمال.

شاید برخی مفاهیم رایج در ماژول Collision Check and Prediction را بعدا پست کردم.
—————
@roboticknowledge

#Planning

این بحث collision checking الگوریتم‌های فراوانی دارد که عمده آن‌ها برای کارهای گرافیکی ایجاد شده‌اند. موتورهای گرافیکی در رندر کردن بازی‌ها و انیمیشن‌ها رفتار اجسام را با در نظر گرفتن برخورد یا عدم برخورد آن‌ها پس از collision checking مدل می‌کنند. در یک صحنه بازی یا انیمیشن هزاران قطعه صلب و الاستیک وجود دارند که در هر فریم باید وضعیت حرکت و برخورد آن‌ها حل شود. در واقع صنعت بازی‌سازی و گرافیک بر این پاشنه می‌چرخد. سرریز این کار به ایجاد safety همراه با ضمانت برای جلوگیری از تصادف در ربات‌های خودران رسیده است!

—————
@roboticknowledge

#Meme

حقیقت در این میم موج می‌زند.

@roboticknowledge

#طراحی

برای طراحی manual را بخوانید.

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

فرضا یک حامل یا career برای یک LiDAR طراحی می‌کنید. در Manual الزامات mount آن سنسور آورده شده است. اگر سنسور گرم شود، نیاز به یک heat sink دارد که احتمالا باید آلومینیومی باشد. فضای مفید آن heat sink و صخامت آن و سطح هواخور ابتدایی‌ترین‌ چیزهایی است که در دفترچه آمده و شما باید در طراحی در نظر بگیرید.

----------
@roboticknowledge

جایی یک رباتی را دیدم که همان LiDAR ای را داشت که من دارم. مستقیم سنسور را بر روی یک career از جنس PLA قرار داده بودند! مشخص بود شخص/تیم طراح الزامات #طراحی را متوجه نشده بود یا اهمیت نداده بود.

----------
@roboticknowledge

https://www.bbc.com/news/videos/cvg3mv3rz60o

----------
@roboticknowledge

#سنسور
#UWB

بر اساس مفهوم ToF نوع دیگری از سنسور وجود دارد که Ultra Wideband نام دارند اما فاصله را بر اساس مسافت طی شده سیگنال الکترومغناطیسی (و نه نور یا لیزز) اندازه‌گیری می‌کنند.

با داشتن چند UWB می‌توان موقعیت یک ربات را با دقت قابل قبولی در یک محیط مشخص تخمین زد. (در محیط‌های ناشناخته و جدید چون ستاپ لازم وجود ندارد چنین چیزی کارایی ندارد و دلیل کاربردهای محدود این سیستم همین است)

این آموزش در این مورد صحبت می‌کند:
https://core-electronics.com.au/guides/sensors/getting-started-with-ultra-wideband-and-measuring-distances-arduino-and-pico-guide/

در برخی از سناریوها و کاربردهای محدود احتمالا می‌‌توان از UWB استفاده کرد. ساده است.

----------
@roboticknowledge