گلو: مڈل ویئر کیوں موجود ہے؟

آپ اب جان چکے ہیں کہ سینسر سسٹم میں ڈیٹا کیسے فیڈ کرتے ہیں اور ایکچویٹرز احکامات کو حرکت میں کیسے بدلتے ہیں۔ لیکن ایک حقیقی روبوٹ میں بہت سے سینسرز اور ایکچویٹرز ہوتے ہیں—ایک IMU، LIDAR، کیمرہ، موٹر کنٹرولرز، گرپر، نیٹ ورک انٹرفیس۔ ان سب کو ایک دوسرے سے بات کرنے کی ضرورت ہے۔ اس مواصلات کو سنبھالنا مڈل ویئر کا کام ہے۔

یہ سبق اس مسئلے کی کھوج کرتا ہے جسے مڈل ویئر حل کرتا ہے اور ROS 2 کا تعارف کراتا ہے، جو روبوٹکس میں مڈل ویئر کا غالب انتخاب ہے۔

مڈل ویئر کے بغیر مسئلہ

تصور کریں کہ آپ ان اجزاء کے ساتھ ایک روبوٹ بنا رہے ہیں:

4 موٹریں (ٹانگوں کے لیے)
1 IMU (اوریئنٹیشن)
1 LIDAR (رکاوٹیں)
1 کیمرہ (ویژن)
2 فورس سینسرز (پاؤں)
1 گرپر موٹر (ہاتھ)

یہ 10 ڈیٹا ذرائع ہیں جو آپ کے مرکزی روبوٹ کنٹرولر میں فیڈ ہو رہے ہیں۔

مڈل ویئر کے بغیر، آپ کے کنٹرولر کو ہر سینسر سے براہ راست کنکشنز کی ضرورت ہوتی ہے:

Motor 1 → (USB cable) → Controller
Motor 2 → (I2C bus) → Controller
Motor 3 → (Ethernet) → Controller
Motor 4 → (Serial) → Controller
IMU → (I2C) → Controller
LIDAR → (USB) → Controller
Camera → (USB) → Controller
Gripper → (PWM) → Controller

اس سے مسائل پیدا ہوتے ہیں:

مسئلہ 1: کپلنگ (Coupling)

اگر آپ LIDAR ماڈل تبدیل کرتے ہیں، تو آپ کو LIDAR ریڈنگ کوڈ دوبارہ لکھنا پڑتا ہے
اگر آپ ایک نیا سینسر شامل کرتے ہیں، تو آپ کو مرکزی کنٹرولر کوڈ کو چھونا پڑتا ہے
کنٹرولر نازک ہے اور ہارڈ ویئر سے سختی سے جڑا ہوا ہے

مسئلہ 2: پیمانہ (Scale)

اگر ایک سینسر خراب ہو جاتا ہے، تو پورا کنٹرولر کریش ہو سکتا ہے
آپ LIDAR چلائے بغیر گرپر کی جانچ نہیں کر سکتے
اجزاء آزاد نہیں ہیں

مسئلہ 3: دوبارہ استعمال (Reusability)

آپ LIDAR ڈیٹا پڑھنے کے لیے کوڈ لکھتے ہیں
ایک ساتھی کو بھی LIDAR ڈیٹا کی ضرورت ہے لیکن وہ اپنا ریڈر لکھتا ہے
آپ کے کوڈ بیس میں "LIDAR ریڈنگ" کے دو مختلف ورژن موجود ہیں

مسئلہ 4: پیچیدگی (Complexity)

10 سینسرز × 10 ممکنہ ریڈرز = 100 مختلف مواصلاتی راستے
ہر راستے میں مختلف پروٹوکول ہینڈلنگ (USB, I2C, Ethernet, serial) ہے
تمام امتزاج کی جانچ کرنا ناممکن ہے

مڈل ویئر حل: پبلش/سبسکرائب (Publish/Subscribe)

مڈل ویئر ایک مرکزی پیغام بس (central message bus) متعارف کراتا ہے جو سینسرز کو صارفین (consumers) سے الگ کرتا ہے:

SENSORS (Publishers)              MIDDLEWARE (Message Bus)           CONSUMERS (Subscribers)
─────────────────────            ───────────────────────            ──────────────────────

Motor 1                           ROS 2 Middleware                   Main Controller
publishes position  ─────┐        Topic: /motor1/position ◄─────┐    subscribes to all
                          │       Topic: /motor2/position ◄──┐  ├─► (all sensor topics)
Motor 2                   │       Topic: /imu/data        ◄─┼──┤
publishes position  ─────┼──────►                          │  └─► Data Logger
                          │       Topic: /lidar/scan      ◄─┤    subscribes to
IMU                       │                                 │    sensor topics
publishes orientation ───┼──────►                          │
                          │                                 └─► Health Monitor
LIDAR                     │                                      subscribes to
publishes point cloud ───┘                                       motor data

کیا بدلا:

سینسرز معروف ٹاپکس (جیسے /motor1/position) پر پبلش کرتے ہیں
جس بھی کوڈ کو اس ڈیٹا کی ضرورت ہوتی ہے وہ ٹاپک کو سبسکرائب کرتا ہے
مڈل ویئر ڈیلیوری سنبھالتا ہے
نئے سبسکرائبرز پبلشرز کو متاثر نہیں کرتے، اور نہ ہی اس کے برعکس

یہ مسائل کو کیوں حل کرتا ہے

ڈی کپلنگ (Decoupling): سینسر تبدیل کیا؟ اس کے پبلشر کو اپ ڈیٹ کریں؛ سبسکرائبرز کو کوئی پرواہ نہیں۔

OLD (direct connection):
If LIDAR moves to /dev/ttyUSB1:
  → Need to edit main controller code
  → Need to rebuild entire system

NEW (middleware):
If LIDAR moves to /dev/ttyUSB1:
  → Update only the LIDAR driver code
  → The topic /lidar/scan still exists
  → Everything else works unchanged

اسکیلنگ (Scaling): ایک نیا صارف (جیسے ڈیٹا لاگر) شامل کریں بغیر پبلشرز کو چھوئے۔

NEW consumer wants motor position?
  → Subscribe to /motor1/position
  → That's it; no changes to motor code

لچک (Resilience): ایک جزو کے خراب ہونے سے پورے سسٹم پر اثر نہیں پڑتا۔

WITHOUT middleware:
LIDAR driver crashes
  → Message bus is down
  → Entire robot stops

WITH middleware:
LIDAR driver crashes
  → /lidar/scan stops publishing
  → Other sensors keep running
  → Main controller notices no LIDAR data, switches to fallback

دوبارہ استعمال (Reusability): ایک LIDAR ریڈر لکھیں، ہر جگہ دوبارہ استعمال کریں۔

LIDAR reader publishes /lidar/scan
  → Main controller subscribes
  → Data logger subscribes
  → Visualization tool subscribes
  → All use the same data source

ROS 2: انڈسٹری کا معیار

ROS 2 (Robot Operating System 2) روبوٹکس میں غالب مڈل ویئر ہے۔ یہ فراہم کرتا ہے:

Topics (پبلش/سبسکرائب): مسلسل ڈیٹا اسٹریمز
- مثال: /sensor_readings/imu سیکنڈ میں 100 بار اورینٹیشن پبلش کرتا ہے
Services (درخواست/جواب - request/response): آن ڈیمانڈ مواصلات
- مثال: کوآرڈینیٹس کے ساتھ /robot/move_to_position کو کال کریں، کامیابی/ناکامی واپس حاصل کریں
Parameters (کنفیگریشن): رن ٹائم پر ایڈجسٹ ہونے کے قابل اقدار
- مثال: /motor_controller/speed_limit کو دوبارہ شروع کیے بغیر تبدیل کیا جا سکتا ہے

ایک سادہ ROS 2 سسٹم

ROS 2 NODES                       ROS 2 TOPICS              ROS 2 SERVICES
───────────                       ────────────              ──────────────

IMU Node                          Topic: /imu/data          Service: /move_to_goal
(publisher)                       │                         │
    │                             ├─ Motor Controller ◄─┐   │
    └────────────────────────────►│   (subscriber)       │   └─ Motor Controller
                                  ├─ Main Controller ◄──┤      (implements)
Motor Controller                  │   (subscriber)       │
(subscriber + publisher)          │                      │
    │                             Topic: /motor/cmd_vel  │
    └────────────────────────────►├─ Main Controller ◄───┘
                                  │   (subscriber)
Main Controller
(subscriber + service caller)
    │
    └──────────────── calls ─────►Service: /move_to_goal

ہر ڈبہ ایک نوڈ (node) ہے (ایک آزاد عمل/process)۔ نوڈز ان کے ذریعے بات چیت کرتے ہیں:

Topics (فائر-اینڈ-فارگیٹ سٹریمنگ)
Services (سماجی درخواست-جواب - synchronous request/response)
Parameters (مشترکہ کنفیگریشن)

کنکشن گنتی مشق

آئیے اسکیلنگ کے فائدے کو ٹھوس بنائیں۔

صورتحال: آپ کے پاس 8 سینسرز اور 5 کنٹرولرز (کوڈ کے ٹکڑے جنہیں سینسر ڈیٹا کی ضرورت ہے) ہیں۔

مڈل ویئر کے بغیر (براہ راست کنکشنز):

ہر 5 کنٹرولرز ہر 8 سینسرز سے جڑتے ہیں
= 5 × 8 = 40 براہ راست کنکشنز کو سنبھالنا ہے
ایک سینسر تبدیل کریں → ممکنہ طور پر تمام 5 کنٹرولرز کو اپ ڈیٹ کریں

مڈل ویئر کے ساتھ (پبلش/سبسکرائب):

8 سینسرز ٹاپکس پر پبلش کرتے ہیں
5 کنٹرولرز مطلوبہ ٹاپکس کو سبسکرائب کرتے ہیں
کل "کنکشنز" = 8 + 5 = 13 (سینسرز پبلش کرتے ہیں، کنٹرولرز سبسکرائب کرتے ہیں)
ایک سینسر تبدیل کریں → صرف اس سینسر کے نوڈ کو اپ ڈیٹ کریں
کنٹرولرز خود بخود نیا ڈیٹا حاصل کرتے ہیں

ایک ہیومنوائڈ روبوٹ تک اسکیلنگ جس میں 100+ سینسرز اور 30 کنٹرولرز ہیں:

براہ راست کنکشنز: 100 × 30 = 3,000 ممکنہ راستے
مڈل ویئر: 100 + 30 = 130 نوڈز

فرق بہت زیادہ ہے۔

اہم بصیرت: معیاری بنانا (Standardization) اہم ہے

ROS 2 معیاری پیغام کی اقسام (standard message types) فراہم کرتا ہے:

sensor_msgs/Imu (IMU ڈیٹا)
sensor_msgs/PointCloud2 (LIDAR ڈیٹا)
geometry_msgs/Twist (ویلوسٹی کمانڈز)

جب ہر کوئی ایک ہی پیغام کی شکل استعمال کرتا ہے:

آپ سینسرز کو تبدیل کر سکتے ہیں اور سافٹ ویئر بغیر کسی تبدیلی کے کام کرتا ہے
اوپن سورس ٹولز (ویژولائزیشن، ریکارڈنگ، تجزیہ) آپ کے ڈیٹا کے ساتھ کام کرتے ہیں
آپ ہر سینسر کے لیے اپنی مرضی کے پارسر نہیں لکھ رہے ہوتے

یہ معیاری بنانا ہی وجہ ہے کہ ROS 2 صرف بہت سے اختیارات میں سے ایک نہیں بلکہ ایک انڈسٹری معیار ہے۔

فلسفہ: مڈل ویئر بطور خلاصہ (Abstraction)

مڈل ویئر سینسرز کیا پیدا کرتے ہیں اور آپ کے کوڈ کو کیا چاہیے کے درمیان بیٹھتا ہے:

Real World                    Middleware                Your Code
(physical sensors      raw data  (standardizes,    standard messages  (clean interfaces,
 with all their        ─────────►buffers,         ──────────────────► predictable data)
 messiness)                      routes)

مڈل ویئر خلاصہ کرتا ہے (abstracts away):

ہارڈ ویئر کی تفصیلات (USB بمقابلہ I2C سے کوئی فرق نہیں پڑتا)
ٹائمنگ کے مسائل (ڈیٹا دیر سے آتا ہے، مڈل ویئر اسے بفر کرتا ہے)
فارمیٹ کے فرق (سینسر آؤٹ پٹ فلوٹس، مڈل ویئر انہیں پیک کرتا ہے)

AI کے ساتھ کوشش کریں

اب جب آپ مڈل ویئر کے مسئلے کو سمجھ چکے ہیں، تو AI اسسٹنٹ کے ساتھ ROS 2 کے حل کو دریافت کریں۔

سیٹ اپ: اپنا AI چیٹ بوٹ کھولیں (ChatGPT, Claude, وغیرہ)۔

پرامپٹ سیٹ:

بنیادی تفہیم:

"I have a robot with 5 sensors and 3 controllers that all need sensor data. Without middleware, how many sensor reading functions would I need to write? If I use ROS 2 middleware with topics, how does that change?"
آرکیٹیکچر ڈیزائن:

"Design a ROS 2 system for a robot that navigates indoors. It has a LIDAR, IMU, camera, and 4 wheel motors. What topics would you create? What nodes? How would data flow?"
ناکامی کے طریقے (Failure modes):

"What happens in a ROS 2 system if: (a) a sensor node crashes, (b) the middleware goes down, (c) a subscriber is slow to process messages?"

متوقع نتائج:

آپ سمجھتے ہیں کہ مڈل ویئر کب فائدہ کا اضافہ کرتا ہے بمقابلہ اوور ہیڈ
آپ ایک سادہ روبوٹ سسٹم کے لیے ROS 2 آرکیٹیکچر کا خاکہ بنا سکتے ہیں
آپ پہچانتے ہیں کہ مڈل ویئر ڈیزائن کے انتخاب سسٹم کی وشوسنییتا کو کیسے متاثر کرتے ہیں

غور کریں (Reflect)

توقف کریں اور غور کریں:

کپلنگ اور جانچ (Testing): اپنے کوڈ میں، کب سخت انحصار نے جانچ کو مشکل بنا دیا؟ یہ براہ راست کنکشن والے روبوٹ کے مسئلے سے کیسے ملتا جلتا ہے؟
معیاری بنانا کا فائدہ: معیاری پیغام کی اقسام استعمال کرنے سے طویل مدتی روبوٹ ڈویلپمنٹ کے لیے کیوں اہمیت ہے؟
سسٹم سوچ: ایک روبوٹ صرف سینسرز اور موٹرز نہیں ہے—یہ سینسرز، مڈل ویئر، اور کنٹرول لاجک ہیں جو مل کر کام کرتے ہیں۔ آپ کیسے جانتے ہیں کہ روبوٹ کے رویے کی ناکامی سینسر کا مسئلہ ہے، مواصلاتی مسئلہ ہے، یا لاجک کا مسئلہ ہے؟

یہ عکاسی آپ کو باب 3 کے لیے تیار کرتی ہے، جہاں آپ عملی طور پر ROS 2 سے ملیں گے اور دیکھیں گے کہ یہ خلاصہ تصورات ٹھوس احکامات اور کوڈ میں کیسے بدل جاتے ہیں۔

مڈل ویئر کے بغیر مسئلہ​

مڈل ویئر حل: پبلش/سبسکرائب (Publish/Subscribe)​

یہ مسائل کو کیوں حل کرتا ہے​

ROS 2: انڈسٹری کا معیار​

ایک سادہ ROS 2 سسٹم​

کنکشن گنتی مشق​

اہم بصیرت: معیاری بنانا (Standardization) اہم ہے​

فلسفہ: مڈل ویئر بطور خلاصہ (Abstraction)​

AI کے ساتھ کوشش کریں​

غور کریں (Reflect)​