Skip to main content

سبق 7.1: کیپ اسٹون تفصیلات (Capstone Specification)

اہم نکتہ (The Key Insight)​

پیشہ ور روبوٹکس میں، یہ اصول حتمی ہے: پہلے تفصیلات (Specification) آتی ہیں۔ کوڈ بعد میں آتا ہے۔

پائیتھن کی ایک بھی لائن لکھنے سے پہلے، ایک بھی پبلشر یا سروس بنانے سے پہلے، آپ یہ واضح کرتے ہیں: سسٹم کو کیا کرنا چاہیے؟ پیغامات کہاں سے کہاں بہتے ہیں؟ ہمیں کیسے پتہ چلے گا کہ کامیابی کب ہوئی؟

یہ سبق آپ کو وہ مہارت سکھاتا ہے۔ اس کے اختتام تک، آپ ایک مکمل تفصیلات لکھ چکے ہوں گے جو اتنی واضح، درست اور غیر مبہم ہوگی کہ کوئی دوسرا شخص اسے نافذ کر سکے—اور صحیح سسٹم حاصل کر سکے۔

کوڈ سے زیادہ تفصیلات کیوں اہم ہیں؟​

سوچیں کہ یہ روبوٹ سسٹم کے لیے کیوں اہم ہے:

صورتحال 1: کوئی تفصیلات نہیں

  • آپ ایک نیویگیٹر (Navigator) نوڈ کا کوڈ لکھنا شروع کرتے ہیں۔
  • آدھے راستے میں، آپ کو احساس ہوتا ہے: "کیا اسے سروس کے ذریعے گول کی درخواستیں لینی چاہئیں یا ٹاپک کے ذریعے؟"
  • آپ پہلے ہی ایک سروس کے لیے آدھا کوڈ لکھ چکے ہیں۔
  • آپ ریفیکٹر (refactor) کرتے ہیں، وقت ضائع کرتے ہیں، شاید بگز (bugs) متعارف کرواتے ہیں۔

صورتحال 2: پہلے تفصیلات

  • آپ لکھتے ہیں: "نیویگیٹر /navigate_to سروس کے ذریعے گول قبول کرتا ہے۔"
  • آپ بالکل وہی نافذ کرتے ہیں۔
  • کوئی حیرت نہیں، کوئی ریفیکٹرنگ نہیں، واضح ڈیزائن کا فیصلہ محفوظ ہو گیا۔
  • کوئی دوسرا شخص آپ کی تفصیلات پڑھتا ہے اور آپ کے ارادے کو سمجھتا ہے۔

پیشہ ور روبوٹک ماہرین تفصیلات کی بنیاد پر کام کرتے ہیں۔ نفاذ شروع ہونے سے پہلے مقصد واضح ہوتا ہے۔

تفصیلات کا ٹیمپلیٹ (The Specification Template)​

یہ وہ ٹیمپلیٹ ہے جسے آپ استعمال کریں گے۔ ہر لائن اہم ہے—ابہام نفاذ کی ناکامی کا سبب بنتا ہے۔

1. مقصد (Intent)​

یہ نظام کیا مسئلہ حل کرتا ہے؟ ایک پیراگراف۔ روبوٹ کیا کرتا ہے اور کیوں، اس بارے میں مخصوص رہیں۔

برا مقصد: "ایک روبوٹ کنٹرولر بنائیں" اچھا مقصد: "ایک ملٹی-نوڈ ROS 2 سسٹم بنائیں جو ایک ٹرٹل سم (turtlesim) ٹرٹل کو گول پوزیشنوں پر نیویگیٹ کرے، اپنی حیثیت مسلسل رپورٹ کرے، اور ایک نقلی سینسر سے آنے والی رکاوٹ کی وارننگز کو بحسن خوبی سنبھالے۔"

دوسرا والا کیوں بہتر ہے؟ یہ ٹھوس (concrete) ہے:

  • دائرہ کار کیا ہے؟ ملٹی-نوڈ، ROS 2
  • مقصد کیا ہے؟ پوزیشنوں پر نیویگیٹ کرنا
  • ڈیٹا کا بہاؤ کیا ہے؟ حیثیت کی رپورٹیں، رکاوٹ کی وارننگز
  • بحسن خوبی سنبھالنا کیا ہے؟ کریش نہیں ہوتا، کام جاری رکھتا ہے۔

2. نظام فن تعمیر (System Architecture)​

کتنے نوڈز؟ ہر ایک کیا کرتا ہے؟ انہیں اس طرح درج کریں:

Navigator Node
  Input: گول پوزیشن (x, y, theta) سروس ریکویسٹ کے ذریعے
  Output: ٹرٹل کو ویلاسٹی کمانڈز
  Purpose: نیویگیشن گول قبول کرتا ہے، راستے کا حساب لگاتا ہے، حرکت کے احکامات جاری کرتا ہے

Status Monitor Node
  Input: موجودہ ٹرٹل حالت (ٹاپکس، اوڈومیٹری سمولیٹر سے)
  Output: روبوٹ کی حیثیت (پوزیشن، ویلاسٹی، بیٹری) ہر 100ms پر شائع ہوتی ہے
  Purpose: ریاستی معلومات کو جمع کرتا ہے، بیرونی سبسکرائبرز کو شائع کرتا ہے

Obstacle Detector Node
  Input: (کوئی نہیں—نقلی سینسر ڈیٹا تیار کرتا ہے)
  Output: ٹاپک پر رکاوٹ کی وارننگز
  Purpose: رکاوٹ کا پتہ لگانے کی نقل کرتا ہے، نیویگیٹر کے سنبھالنے کے لیے وارننگز شائع کرتا ہے

ہر نوڈ میں ان پٹ، آؤٹ پٹ، اور مقصد (purpose) ہوتا ہے۔ کوئی راز نہیں۔ کوئی ابہام نہیں۔

3. انٹرفیسز (Topics & Services)​

نوڈز کے درمیان معاہدہ کیا ہے؟ ہر ٹاپک اور سروس کی وضاحت کریں:

Service: /navigate_to
  Request: x (float), y (float), theta (float)
  Response: success (bool), time_taken (float)
  Purpose: نیویگیشن گول قبول کریں، تکمیل کی حیثیت اور وقت واپس کریں

Topic: /robot/status (کسٹم TurtleStatus میسج)
  Message fields: x (float), y (float), theta (float), vel_x (float), vel_y (float), battery (float)
  Frequency: 10 Hz (ہر 100ms)
  Subscribers: اسٹیٹس مانیٹر، یا بیرونی مانیٹرنگ نوڈز
  Purpose: روبوٹ کی حالت مسلسل شائع کریں

Topic: /obstacles (sensor_msgs/LaserScan نقلی)
  Message fields: angle_min, angle_max, distances (array)
  Frequency: 5 Hz
  Publishers: رکاوٹ کا پتہ لگانے والا نوڈ
  Purpose: نیویگیٹر کے عمل کرنے کے لیے نقلی رکاوٹ کا ڈیٹا

اتنی تفصیل کیوں؟ جب نفاذ کیا جاتا ہے، تو ڈویلپر اسے پڑھتا ہے اور جانتا ہے:

  • بالکل کون سے میسج ٹائپس استعمال کرنے ہیں
  • ڈیٹا کتنی بار بہتا ہے
  • کون شائع کرتا ہے، کون سبسکرائب کرتا ہے
  • کسٹم میسجز میں کون سے فیلڈز جاتے ہیں

4. کامیابی کے معیار (Success Criteria)​

آپ کو کیسے پتہ چلے گا کہ یہ کام کر گیا؟ قابل پیمائش، جانچنے کے قابل شرائط:

✅ ٹرٹل سروس کال کے 2 سیکنڈ کے اندر گول پوزیشن پر پہنچ جاتا ہے
✅ اسٹیٹس میسجز ہر 100ms پر شائع ہوتے ہیں (±10ms رواداری قابل قبول)
✅ سسٹم 3+ رکاوٹیں پتہ لگنے پر کام جاری رکھتا ہے (کوئی کریش نہیں، کوئی فریز نہیں)
✅ لانچ فائل `ros2 launch` کے ساتھ تمام نوڈز کو درست پیرامیٹرز کے ساتھ شروع کرتی ہے
✅ نیویگیٹر نوڈ 5+ منٹ تک بغیر کسی خرابی کے چلتا ہے
✅ سروس اصل حرکت کے وقت کے 0.1 سیکنڈ کے اندر تکمیل کا وقت واپس کرتی ہے

قابل پیمائش کیوں؟ آپ ان میں سے ہر ایک کو سبق 7.3 میں واضح طور پر جانچیں گے۔

5. غیر اہداف (Non-Goals)​

دائرہ کار میں کیا شامل نہیں ہے؟ ان کو واضح طور پر خارج کرنے سے دائرہ کار کا بڑھنا رکتا ہے:

❌ حقیقی رکاوٹ سے بچاؤ (صرف پتہ لگانا، رکاوٹوں کے گرد راستے کی منصوبہ بندی نہیں)
❌ حقیقی LIDAR سمولیشن (صرف نقلی سینسر، مکمل فزکس نہیں)
❌ ایک سے زیادہ ٹرٹلز (صرف ایک ٹرٹل)
❌ URDF یا روبوٹ کی تفصیل (ماڈیول 2 تک ملتوی)
❌ حقیقی ہارڈ ویئر تعیناتی (صرف سمولیشن)
❌ بصری راستے کا تصور (صرف لاگنگ/ڈیبگنگ)

"کیا شامل نہیں ہے" لکھنا اتنا ہی اہم ہے جتنا "کیا شامل ہے" لکھنا۔

آپ کا تفصیلات کا ٹیمپلیٹ​

اب آپ اسے پُر کریں۔ یہ ٹیمپلیٹ استعمال کریں:

# ٹرٹل روبوٹ کنٹرولر تفصیلات

## مقصد (Intent)
[ایک پیراگراف جو بیان کرتا ہے کہ یہ نظام کیا کرتا ہے، ٹھوس طور پر]

## نظام فن تعمیر (System Architecture)

### Navigator Node
Input: [یہ کیا وصول کرتا ہے؟]
Output: [یہ کیا پیدا کرتا ہے؟]
Purpose: [یہ کیوں موجود ہے؟]

### Status Monitor Node
Input: [یہ کیا وصول کرتا ہے؟]
Output: [یہ کیا پیدا کرتا ہے؟]
Purpose: [یہ کیوں موجود ہے؟]

### Obstacle Detector Node
Input: [یہ کیا وصول کرتا ہے؟]
Output: [یہ کیا پیدا کرتا ہے؟]
Purpose: [یہ کیوں موجود ہے؟]

## انٹرفیسز (Interfaces)

### Service: /navigate_to
Request: [فیلڈز]
Response: [فیلڈز]
Purpose: [یہ سروس کیوں ہے؟]

### Topic: /robot/status
Message Type: [کسٹم یا معیاری؟]
Fields: [ہر فیلڈ کی فہرست دیں]
Frequency: [Hz یا ms؟]
Purpose: [یہ ٹاپک کیوں ہے؟]

### Topic: /obstacles
Message Type: [کسٹم یا معیاری؟]
Fields: [ہر فیلڈ کی فہرست دیں]
Frequency: [Hz یا ms؟]
Purpose: [یہ ٹاپک کیوں ہے؟]

## کامیابی کے معیار (Success Criteria)

✅ [ٹھوس، قابل پیمائش معیار 1]
✅ [ٹھوس، قابل پیمائش معیار 2]
✅ [ٹھوس، قابل پیمائش معیار 3]
✅ [ٹھوس، قابل پیمائش معیار 4]
✅ [ٹھوس، قابل پیمائش معیار 5]

## غیر اہداف (Non-Goals)

❌ [کیا دائرہ کار میں نہیں ہے 1]
❌ [کیا دائرہ کار میں نہیں ہے 2]
❌ [کیا دائرہ کار میں نہیں ہے 3]

ایک تفصیلات کو کیا چیز اچھی بناتی ہے؟​

ان معیاروں پر اس کی جانچ کریں​

معیار 1: وضاحت (Clarity)

  • کیا کوئی ڈویلپر جو آپ سے نہیں ملا، صرف آپ کی تفصیلات سے اسے نافذ کر سکتا ہے؟
  • ہاتھ ہلانا ("رکاوٹوں کو ذہانت سے سنبھالتا ہے") نہیں—مخصوص رہیں
  • مبہم الفاظ ("بہترین راستہ") نہیں—بالکل واضح کریں کہ آپ کا کیا مطلب ہے

معیار 2: مکمل پن (Completeness)

  • ہر ٹاپک کی میسج ٹائپ بیان کی گئی ہے
  • ہر سروس کی ریکویسٹ/رسپانس ٹائپس بیان کی گئی ہیں
  • ہر نوڈ کے ان پٹ اور آؤٹ پٹ ہیں
  • اندازہ لگانے کے لیے کچھ بھی باقی نہیں

معیار 3: جانچنے کی صلاحیت (Testability)

  • ہر کامیابی کا معیار قابل پیمائش ہے
  • آپ اسے ros2 topic echo یا سروس کالز سے جانچ سکتے ہیں
  • آپ ایک ٹیسٹ اسکرپٹ لکھ سکتے ہیں جو ہر معیار کو درست ثابت کرے۔

معیار 4: حقیقت پسندی (Realism)

  • کیا تفصیلات 90 منٹ میں قابل حصول ہیں؟
  • کیا کامیابی کے معیار مناسب ہیں؟
  • کیا یہ آپ کی مہارتوں کو بڑھاتا ہے لیکن انہیں توڑتا نہیں ہے؟

عام تفصیلات کی غلطیاں جن سے بچنا چاہیے​

غلطی 1: مبہم کامیابی کے معیار​

برا: "ٹرٹل گول تک پہنچ جاتا ہے" اچھا: "ٹرٹل 2 سیکنڈ کے اندر گول پوزیشن پر پہنچ جاتا ہے، جس میں پوزیشن کی غلطی < 0.1m ہو"

کیوں؟ پہلا والا مبہم ہے۔ "پہنچنا" کیا شمار ہوتا ہے؟ دوسرا جانچنے کے قابل ہے۔

غلطی 2: نوڈ کی ذمہ داریوں کا غائب ہونا​

برا: "سسٹم ٹرٹل کو کنٹرول کرتا ہے" اچھا: "نیویگیٹر نوڈ ویلاسٹی کمانڈز کا حساب لگاتا ہے؛ اسٹیٹس مانیٹر حیثیت شائع کرتا ہے؛ آبسٹیکل ڈیٹیکٹر وارننگز شائع کرتا ہے"

کیوں؟ برا ورژن واضح نہیں کرتا کہ کون کیا کرتا ہے۔ اچھا ورژن خدشات کی واضح تقسیم کرتا ہے۔

غلطی 3: میسج ٹائپس کا نہ ہونا​

برا: "نوڈز ٹاپکس کے ذریعے بات چیت کرتے ہیں" اچھا: "اسٹیٹس مانیٹر TurtleStatus (کسٹم میسج جس میں x, y, theta, vel_x, vel_y, battery فیلڈز ہیں) 10 Hz پر شائع کرتا ہے"

کیوں؟ میسج ٹائپس کے بغیر، نافذ کرنے والے کو انہیں ایجاد کرنا پڑتا ہے۔ ٹائپس کے ساتھ، نفاذ سیدھا ہے۔

غلطی 4: غیر حقیقی وقت کی پابندیاں​

برا: "ٹرٹل 0.1 سیکنڈ میں گول تک پہنچ جاتا ہے" اچھا: "ٹرٹل 2 سیکنڈ میں گول تک پہنچ جاتا ہے" (turtlesim حرکت کے لیے حقیقت پسندانہ)

کیوں؟ اگر آپ کی تفصیلات ناممکن ہیں، تو نفاذ ناکام ہو جاتا ہے۔ کامیابی کے معیار قابل حصول بنائیں۔

ٹرٹل تفصیلات کی مثال (حوالہ کے لیے)​

یہ دیکھیں کہ مکمل شدہ تفصیلات کیسی نظر آتی ہیں:

# ٹرٹل روبوٹ کنٹرولر تفصیلات

## مقصد (Intent)
ایک ملٹی-نوڈ ROS 2 سسٹم بنائیں جو خود مختار نیویگیشن اہداف کے حصول کے لیے ایک ٹرٹل سم ٹرٹل کو کنٹرول کرے۔ سسٹم سروس کال کے ذریعے گول پوزیشن قبول کرتا ہے، مسلسل اسٹیٹس اپ ڈیٹس شائع کرتا ہے، اور بغیر کریش ہوئے یا کنٹرول کھوئے نقلی رکاوٹ کی وارننگز کو بحسن خوبی سنبھالتا ہے۔

## نظام فن تعمیر (System Architecture)

### Navigator Node
Input: گول پوزیشن (x, y, theta) /navigate_to سروس ریکویسٹ کے ذریعے
Output: ٹرٹل کو ویلاسٹی کمانڈز (cmd_vel)؛ گول کی تکمیل کا جواب
Purpose: حرکت کو گول کی طرف منظم کرتا ہے۔ سروس کے ذریعے نئے گول قبول کرتا ہے۔
         گول کی بنیاد پر ویلاسٹی کمانڈز کا حساب لگاتا ہے۔ مکمل ہونے پر کامیابی/وقت واپس کرتا ہے۔

### Status Monitor Node
Input: ٹرٹل اوڈومیٹری (پوز، ویلاسٹی) — یا تو /turtle1/pose ٹاپک سے
       یا دستیاب ہونے پر cmd_vel/odom سے شمار شدہ
Output: /robot/status ٹاپک (کسٹم TurtleStatus میسج)
Purpose: روبوٹ کی حالت (پوزیشن، ویلاسٹی، بیٹری) مسلسل شائع کرتا ہے تاکہ بیرونی نگرانی کی جا سکے۔
         دیگر نوڈز کو ریاستی تبدیلیوں پر رد عمل ظاہر کرنے کے قابل بناتا ہے۔

### Obstacle Detector Node
Input: (کوئی نہیں—نقلی ڈیٹا تیار کرتا ہے)
Output: /obstacles ٹاپک (sensor_msgs/LaserScan نقلی ڈھانچہ)
Purpose: رکاوٹ کا پتہ لگانے کی نقل کرتا ہے۔ وقتاً فوقتاً "پتہ لگانے" شائع کرتا ہے جسے
         نیویگیٹر سنبھال سکتا ہے۔ سسٹم کی مضبوطی کو جانچتا ہے۔

## انٹرفیسز (Interfaces)

### Service: /navigate_to
Request:
  - x (float): ٹرٹل کوآرڈینیٹ سسٹم میں گول X پوزیشن
  - y (float): ٹرٹل کوآرڈینیٹ سسٹم میں گول Y پوزیشن
  - theta (float): ڈگری میں گول سمت (0-360)
Response:
  - success (bool): اگر گول پہنچ گیا تو True، اگر منسوخ ہوا تو False
  - time_taken (float): ریکویسٹ سے تکمیل تک گزرا ہوا وقت سیکنڈ میں
Purpose: بنیادی کمانڈ انٹرفیس۔ کلائنٹس پوزیشن پر نیویگیشن کی درخواست کرتے ہیں۔
         نیویگیٹر گول سنبھالتا ہے اور حیثیت واپس کرتا ہے۔

### Topic: /robot/status
Message Type: TurtleStatus (کسٹم)
Fields:
  - x (float): موجودہ X پوزیشن
  - y (float): موجودہ Y پوزیشن
  - theta (float): موجودہ سمت (ڈگری)
  - vel_x (float): X سمت میں ویلاسٹی
  - vel_y (float): Y سمت میں ویلاسٹی
  - battery (float): نقلی بیٹری لیول (0-100%)
Frequency: 10 Hz (ہر 100ms)
Subscribers: اسٹیٹس مانیٹر ڈیش بورڈ، بیرونی فیصلہ سازی کے نظام
Purpose: حقیقی وقت کا ریاستی سلسلہ۔ فعال رویے اور نگرانی کو قابل بناتا ہے۔

### Topic: /obstacles
Message Type: sensor_msgs/LaserScan (سادہ نقلی)
Fields:
  - angle_min, angle_max: پتہ لگانے کی زاویہ کی حد
  - ranges: فاصلے کی پیمائش کا صف (simulated)
Frequency: 5 Hz (ہر 200ms)
Publishers: آبسٹیکل ڈیٹیکٹر نوڈ
Purpose: نقلی سینسر ڈیٹا۔ نیویگیٹر سبسکرائب کرتا ہے اور رکاوٹ کا پتہ لگنے پر رک جاتا ہے/سنبھالتا ہے۔
         سینسر ان پٹ کو سنبھالنے کی جانچ کرتا ہے۔

## کامیابی کے معیار (Success Criteria)

✅ سروس /navigate_to گول قبول کرتی ہے اور جب ٹرٹل 0.2m کے اندر پوزیشن پر پہنچ جاتا ہے تو success=true واپس کرتی ہے
✅ ٹرٹل سروس ریکویسٹ سے 2 سیکنڈ کے اندر گول تک پہنچ جاتا ہے
✅ اسٹیٹس ٹاپک ہر 100ms پر TurtleStatus میسج شائع کرتا ہے (±10ms تغیر قابل قبول ہے)
✅ سسٹم کریش ہوئے بغیر 10+ رکاوٹ پیغامات وصول اور لاگ کرتا ہے
✅ لانچ فائل `ros2 launch robot_controller start_system.launch.py` تمام نوڈز اور پیرامیٹرز کو شروع کرتی ہے
✅ نیویگیٹر نوڈ 5+ منٹ تک بغیر کسی خرابی کے مسلسل چلتا ہے
✅ کسٹم TurtleStatus میسج مرتب (compile) ہوتا ہے اور درست طریقے سے سیریلائز ہوتا ہے

## غیر اہداف (Non-Goals)

❌ حقیقی رکاوٹ سے بچاؤ (سسٹم رکاوٹوں کا پتہ لگاتا ہے لیکن ان کے گرد راستے کی منصوبہ بندی نہیں کرتا)
❌ حقیقت پسندانہ LIDAR سمولیشن (صرف نقلی سینسر، فزکس پر مبنی نہیں)
❌ ایک سے زیادہ ٹرٹلز یا ایجنٹوں کے درمیان رابطہ
❌ روبوٹ URDF یا کائنی میٹکس (صرف براہ راست ویلاسٹی کمانڈز)
❌ حقیقی ہارڈ ویئر تعیناتی (صرف turtlesim سمولیشن)
❌ راستے کی منصوبہ بندی یا ٹراجیکٹری آپٹیمائزیشن (سیدھی لکیر میں حرکت قابل قبول ہے)
❌ بصری RViz تصور (صرف CLI توثیق)

نظام فن تعمیر کا خاکہ (System Architecture Diagram)​

یہاں بتایا گیا ہے کہ نوڈز کیسے تعامل کرتے ہیں:

┌─────────────────────────────────────────────────────┐
│         ٹرٹل روبوٹ کنٹرولر سسٹم                   │
├─────────────────────────────────────────────────────┤
│                                                       │
│  کلائنٹ ایپ                                          │
│     │                                                │
│     │ (سروس کال: /navigate_to)                        │
│     ↓                                                │
│  ┌──────────────────────────────────────────┐       │
│  │ Navigator Node                            │       │
│  │  ├─ Input: گول (x,y,theta) سروس کے ذریعے  │       │
│  │  ├─ حساب کرتا ہے: ویلاسٹی کمانڈز          │       │
│  │  └─ Output: cmd_vel ٹرٹل سم کو             │       │
│  └──────────────────────────────────────────┘       │
│     │ (cmd_vel)          │ (/navigate_to جواب)       │
│     │                    └────────────► کلائنٹ       │
│     ↓                                                │
│  [TurtleSim Turtle]◄────────────────────────────┐   │
│     │ (اپ ڈیٹ شدہ پوز)                            │   │
│     ↓                                            │   │
│  ┌──────────────────────────────────────────┐   │   │
│  │ Status Monitor Node                       │   │   │
│  │  ├─ Input: ٹرٹل پوز/اوڈومیٹری          │   │   │
│  │  ├─ جمع کرتا ہے: پوزیشن، ویلاسٹی، بیٹری
│  │  └─ Output: /robot/status (10 Hz)        │───┤   │
│  └──────────────────────────────────────────┘   │   │
│                                                  │   │
│  ┌──────────────────────────────────────────┐   │   │
│  │ Obstacle Detector Node                    │   │   │
│  │  ├─ Input: (تیار کردہ نقلی ڈیٹا)          │   │   │
│  │  └─ Output: /obstacles (5 Hz) ───────────┼───┴──→ نیویگیٹر
│  └──────────────────────────────────────────┘       │
│                                                       │
└─────────────────────────────────────────────────────┘

AI کے ساتھ کوشش کریں (Try With AI)​

سیٹ اپ: آپ اپنی تفصیلات کو بہتر بنانے کے لیے ایک چیٹ AI (Claude, ChatGPT, یا GitHub Copilot) استعمال کریں گے۔

مرحلہ 1: اپنی تفصیلات کا مسودہ بنائیں

سب سے پہلے، اوپر دیے گئے ٹیمپلیٹ کا استعمال کرتے ہوئے اپنی خاکہ تفصیلات لکھیں۔ آپ اس میں یہ شامل کر سکتے ہیں:

  • ٹھوس تفصیلات (حقیقی نوڈ کے نام، حقیقی میسج ٹائپس جیسے sensor_msgs/LaserScan)
  • یا اعلیٰ سطحی خیالات (جنہیں آپ مرحلہ 2 میں بہتر بنا سکتے ہیں)

مرحلہ 2: AI بہتری کے لیے پرامپٹس

ایک بار جب آپ کا مسودہ تیار ہو جائے، تو اپنے AI کے ساتھ یہ پرامپٹس استعمال کریں:

پرامپٹ 1: وضاحت کی جانچ

میں نے ٹرٹل کنٹرولر کے لیے یہ ROS 2 تفصیلات لکھی ہیں:

[اپنی تفصیلات پیسٹ کریں]

کیا کوئی ایسا حصہ ہے جو مبہم یا غیر واضح ہے؟
ایسا کہاں ہوگا جہاں ڈویلپر کو اس پر عمل درآمد کرتے ہوئے الجھن ہوگی؟
کون سی تفصیلات غائب ہیں؟

پرامپٹ 2: مکمل پن کی جانچ

میری تفصیلات کو دیکھتے ہوئے، کیا میں نے یہ سب بیان کیا ہے:
- تمام میسج ٹائپس (کون سے فیلڈز، کون سی ٹائپس؟)
- تمام ٹاپکس (کون شائع کرتا ہے، کون سبسکرائب کرتا ہے، کس فریکوئنسی پر؟)
- تمام سروسز (ریکویسٹ/رسپانس ڈھانچہ کیا ہے؟)
- تمام نوڈ کی ذمہ داریاں (ہر نوڈ کیا کرتا ہے؟)

کہاں خلا ہیں؟

پرامپٹ 3: جانچنے کی صلاحیت کی جانچ

کیا ان میں سے ہر کامیابی کے معیار کو ROS 2 CLI ٹولز سے جانچا جا سکتا ہے؟

[اپنے کامیابی کے معیار پیسٹ کریں]

کون سے جانچے جا سکتے ہیں؟ کون سے جانچنے کے لیے بہت مبہم ہیں؟
میں ہر ایک کے لیے ٹیسٹ کیسے لکھوں گا؟

متوقع نتیجہ: آپ کی بہتر تفصیلات اتنی واضح ہونی چاہئیں کہ:

  • ایک ڈویلپر بغیر سوالات پوچھے اسے نافذ کر سکے
  • آپ ہر کامیابی کے معیار کو ٹھوس ROS 2 کمانڈز سے جانچ سکیں
  • آپ کے پاس کوئی مبہم الفاظ نہ ہوں (جیسے "ذہانت سے"، "بہترین"، "اچھی طرح")

حفاظتی نوٹ: آپ کا AI کبھی کبھی ضرورت سے زیادہ پیچیدہ تفصیلات تجویز کرے گا (ماڈیول کے دائرہ کار سے باہر کی خصوصیات شامل کرنا)۔ یاد رکھیں: غیر اہداف میں URDF، ایکشنز، tf2، اور حقیقی رکاوٹ سے بچاؤ شامل نہیں ہیں۔ اسے سادہ رکھیں—صرف چیپٹرز 4-6 سے pub/sub، سروسز، پیرامیٹرز، اور لانچ فائلوں پر توجہ دیں۔

اختیاری توسیع: اپنی تفصیلات کو PlantUML یا Mermaid ڈایاگرام کی شکل میں لکھیں جو نوڈ مواصلات کو دکھائے۔ یہ آپ کو فن تعمیر کے بارے میں بصری طور پر سوچنے پر مجبور کرے گا۔

اگلا قدم: سبق 7.2: کنٹرولر بنانا →