Multi-Agent Planning with Spatio-Temporal and Topological Constraints using STL-GO

कल्पना कीजिए कि एक ऐसी दुनिया है जहाँ ड्रोन्स का एक झुंड केवल बेतरतीब ढंग से नहीं उड़ता, बल्कि एक एकल, अत्यंत बुद्धिमान मस्तिष्क की तरह कार्य करता है। यह मल्टी-एजेंट सिस्टम्स (Multi-Agent Systems) का क्षेत्र है, जो कंप्यूटर विज्ञान की एक शाखा है जहाँ कई रोबोट मिलकर बड़ी समस्याओं को हल करते हैं, जैसे कि जंगल की आग बुझाना या खोए हुए हाइकर्स की तलाश करना। यह सुनिश्चित करने के लिए कि ये रोबोट आपस में न टकराएं या अपना काम न भूल जाएं, इंजीनियर "फॉर्मल मेथड्स" (formal methods) का उपयोग करते हैं—जो कि एक फैंसी तरीका है यह कहने का कि वे रोबोट्स के पालन करने के लिए सख्त, गणितीय नियम पुस्तिकाएं लिखते हैं। आमतौर पर, ये नियम पुस्तिकाएं सरल यातायात नियमों की तरह होती हैं: "लाल बत्ती पर रुकें" या "20 मील प्रति घंटे से तेज़ न चलें।" लेकिन वास्तविक जीवन अधिक जटिल है। कभी-कभी, एक रोबोट को यह जानने की आवश्यकता होती है, "क्या मेरा दोस्त पास में है? क्या मैं उनसे बात कर सकता हूँ? क्या उन्होंने आग देखी?" इसके लिए एक ऐसी नियम पुस्तिका की आवश्यकता होती है जो न केवल समय और स्थान को, बल्कि टोपोलॉजी (topology)—यानी रोबोट्स के बीच संबंधों के आकार को भी समझती हो। इसे एक अकेले कार के नियमों की सूची और एक पूरे डांस ट्रूप (नृत्य दल) के नियमों की पुस्तिका के बीच के अंतर के रूप में समझें, जो हर सेकंड अपने साथी बदलते रहते हैं।

यह शोध पत्र इस पेचीदा समस्या को हल करता है कि रोबोट्स के झुंड को उनके "दोस्ती के मानचित्र" (friendship map) के लगातार बदलते रहने पर भी अपनी गतिविधियों की योजना बनाना कैसे सिखाया जाए। लेखक एक नई, अत्यंत शक्तिशाली नियम पुस्तिका भाषा पेश करते हैं जिसे STL-GO (Spatio-Temporal Logic with Graph Operators) कहा जाता है। जबकि पिछली भाषाएँ समय और स्थान को संभाल सकती थीं, वे इस बात को संभालने में संघर्ष करती थीं कि कौन किससे बात कर रहा है, इसका जटिल और बदलता हुआ जाल। शोधकर्ताओं ने दो अलग-अलग "अनुवादक" (एक मिक्स्ड-इंटीजर प्रोग्रामिंग पर आधारित और दूसरा सैटिस्फिएबिलिटी मोड्यूलो थ्योरी पर आधारित) बनाए जो इन जटिल, बदलते नियमों को ले सकते हैं और उन्हें रोबोट्स के लिए एक ठोस उड़ान योजना में बदल सकते हैं। उन्होंने इन अनुवादकों का परीक्षण लोकेटर ड्रोन्स (खोजकर्ता) और रेस्क्यूअर ड्रोन्स (बचावकर्ता) से जुड़े एक सिम्युलेटेड बचाव मिशन में किया। उनके परिणाम दिखाते हैं कि जबकि यह नया तरीका जटिल टीम वर्क को संभालने के लिए पर्याप्त शक्तिशाली है, यह गणनात्मक रूप से भारी (computationally heavy) हो सकता है, जिसमें एक विधि विशिष्ट कार्य के आधार पर दूसरी विधि की तुलना में तेजी से समस्या को हल करती है।

बदलते झुंड की कहानी

कल्पना कीजिए कि आप दो प्रकार के ड्रोन्स से बनी एक बचाव टीम के कमांडर हैं: लोकैटर्स (Locators) (खोजकर्ता) और रेस्क्यूअर्स (Rescuers) (नायक)। लोकैटर्स जंगल में आग की तलाश में इधर-उधर उड़ते हैं। जब एक लोकेटर आग देखता है, तो उसे कुछ विशिष्ट क्रम में चीजें करनी होती हैं:

1. सेंस (Sense): पुष्टि करें कि आग असली है।
2. कनेक्ट (Connect): अन्य लोकैटर्स और रेस्क्यूअर्स को चिल्लाकर सूचित करें कि "यहाँ आग है!"
3. असाइन (Assign): मदद के लिए एक विशिष्ट रेस्क्यूअर को चुनें।
4. एक्ट (Act): रेस्क्यूअर आग तक जाता है, एक जीवित बचे व्यक्ति को उठाता है, और उन्हें एक सुरक्षित टेंट तक ले जाता है।

चुनौती क्या है? "चिल्लाने" वाला हिस्सा हवा, बैटरी स्तर और ड्रोन कहाँ उड़ रहे हैं, इस पर निर्भर करता है। कभी-कभी एक लोकेटर एक रेस्क्यूअर से बात कर सकता है; कभी-कभी नहीं। कभी-कभी रेस्क्यूअर इतना दूर होता है कि वह सुन नहीं पाता। कौन किससे बात कर सकता है, इसका मानचित्र एक डायनेमिक ग्राफ (dynamic graph) है—कनेक्शन का एक ऐसा जाल जो हर सेकंड बदलता रहता है।

लेखकों ने जिस समस्या को हल किया है वह यह है: हम कंप्यूटर प्रोग्राम कैसे लिखें जो इन ड्रोन्स के सटीक उड़ान पथ निर्धारित कर सके ताकि वे नियमों का पालन करें, भले ही उनके कनेक्शन लगातार बदलते रहें?

जादुई नियम पुस्तिका: STL-GO

लेखकों ने STL-GO नामक एक विशेष भाषा का उपयोग किया है। इस भाषा को निर्देशों को लिखने के एक तरीके के रूप में समझें जो कह सकते हैं:

• "प्रत्येक आग को 5 मिनट के भीतर एक लोकेटर द्वारा देखा जाना चाहिए।"
• "देखने के बाद, लोकेटर को 2 मिनट के भीतर कम से कम एक रेस्क्यूअर को खोजना होगा जिससे वह बात कर सके।"
• "रेस्क्यूअर को फिर आग तक उड़ना होगा और जीवित बचे व्यक्ति को टेंट तक लाना होगा।"

STL-GO में "ग्राफ ऑपरेटर्स" (Graph Operators) गुप्त सूत्र हैं। वे इस भाषा को यह कहने की अनुमति देते हैं: "वर्तमान कनेक्शनों के मानचित्र की जाँच करें। क्या लोकेटर से रेस्क्यूअर तक कोई मार्ग है?" यह केवल "निर्देशांक X, Y पर जाओ" कहने की तुलना में बहुत कठिन है। इसके लिए कंप्यूटर को टीम के नेटवर्क के आकार का निरंतर पुनर्मूल्यांकन करने की आवश्यकता होती है।

दो अनुवादक: MIP और SMT

नियम लिखना एक बात है; रोबोट्स को वास्तव में उड़ाना दूसरी बात है। कंप्यूटर को इन उच्च-स्तरीय नियमों को कदमों की एक सूची (जैसे "5 मीटर आगे बढ़ें, बाएं मुड़ें") में अनुवाद करने की आवश्यकता होती। शोध पत्र इन कार्यों को करने के लिए दो अलग-अलग "अनुवादकों" को प्रस्तुत करता है:

1. MIP अनुवादक (Mixed-Integer Programming): कल्पना कीजिए कि यह एक बहुत ही सख्त, विवरण-उन्मुख अकाउंटेंट (लेखाकार) है। यह केवल कोई भी योजना नहीं, बल्कि सर्वश्रेष्ठ संभव योजना खोजने की कोशिश करता है। इसे यह बताया जा सकता है, "एक ऐसा रास्ता खोजें जो सबसे कम बैटरी का उपयोग करे।" यह तब बहुत अच्छा है जब आप ऊर्जा बचाना चाहते हैं, लेकिन यह धीमा और भारी हो सकता है, जैसे जग्गलिंग (गेंद उछालने का खेल) करते समय एक विशाल सुडोकू पहेली को हल करने की कोशिश करना।
2. SMT अनुवादक (Satisfiability Modulo Theory): इसे एक बिजली की गति से काम करने वाले जासूस के रूप में समझें। इसे "सर्वश्रेष्ठ" योजना खोजने की परवाह नहीं है; यह बस एक ऐसी योजना चाहता है जो काम करे। यह पूछता है, "क्या इन सभी नियमों को पूरा करना संभव है?" यदि हाँ, तो यह आपको एक समाधान देता है। यह आमतौर पर अकाउंटेंट की तुलना में बहुत तेज़ होता है, लेकिन यह ईंधन दक्षता जैसी चीजों के लिए अनुकूलन (optimize) नहीं कर सकता।

बचाव सिमुलेशन (Rescue Simulation)

अपने विचारों का परीक्षण करने के लिए, लेखकों ने जंगल की आग के बचाव का एक सिमुलेशन बनाया। उन्होंने लोकैटर्स और रेस्क्यूअर्स के साथ एक परिदृश्य तैयार किया और कंप्यूटर को एक मिशन की योजना बनाने के लिए कहा जहाँ:

• आग अलग-अलग स्थानों पर लग सकती थी।
• ड्रोन्स को संचार करना था और इस आधार पर कार्य सौंपने थे कि वे बात करने के लिए कितने करीब थे।
• यह सब एक विशिष्ट समय सीमा के भीतर होना था।

उन्होंने विभिन्न टीम आकारों (5 लोकैटर्स से 9 लोकैटर्स तक) और विभिन्न जटिलता स्तरों (केवल सेंसिंग, प्लस कम्युनिकेशन, प्लस टास्क असाइनमेंट) के साथ सिमुलेशन चलाया।

उन्होंने क्या पाया:

• SMT अनुवादक एक स्पीडस्टर (तेज दौड़ने वाला) था। लगभग हर परीक्षण में, इसने MIP अनुवादक की तुलना में बहुत तेज़ी से एक वैध उड़ान योजना खोजी। उदाहरण के लिए, 9 लोकैटर्स और 3 रेस्क्यूअर्स की टीम के साथ, SMT अनुवादक ने समस्या को लगभग 16.5 सेकंड में हल कर दिया, जबकि MIP अनुवादक को 1,480 सेकंड से अधिक समय लगा (और वह अभी भी पूर्णतः सर्वश्रेष्ठ योजना नहीं, बल्कि केवल एक अच्छी योजना ही खोज पाया था)।
• MIP अनुवादक एक ऑप्टिमाइज़र (अनुकूलक) था। जब लेखकों ने MIP अनुवादक को सबसे सीधा, ईंधन-कुशल पथ खोजने के लिए कहा, तो इसने ड्रोन्स की गतिविधियों को आकार देने में बहुत अच्छा काम किया, जबकि SMT अनुवादक ने केवल वही पथ दिया जो काम करता था।
• जटिलता मायने रखती है। जैसे-जैसे उन्होंने अधिक नियम जोड़े (जैसे विशिष्ट संचार लिंक या कार्य असाइनमेंट की आवश्यकता), समस्या दोनों के लिए कठिन हो गई। लेकिन MIP अनुवादक सबसे अधिक संघर्ष करता है, क्योंकि जैसे-जैसे टीम बड़ी होती है, वेरिएबल्स और बाधाओं की संख्या विस्फोट की तरह बढ़ती जाती है।

यह क्यों महत्वपूर्ण है

यह शोध पत्र यह दावा नहीं करता कि इसने रोबोट झुंडों की हर समस्या को हल कर लिया है। लेखक सावधानीपूर्वक नोट करते हैं कि उनके परिणाम सिमुलेशन पर आधारित हैं जहाँ वातावरण पूरी तरह से अनुमानित (जैसे अचानक हवा का झोंका या खराब रेडियो सिग्नल नहीं) है। वास्तविक दुनिया में, चीजें अव्यवस्थित होती हैं, और इन योजनाओं को चलते समय समायोजित करने की आवश्यकता हो सकती है।

हालाँकि, उन्होंने सफलतापूर्वक दिखाया है कि रोबोट टीमों के लिए जटिल, बदलते नियम लिखना और कंप्यूटर से उन्हें उड़ाने की योजना बनाना संभव है। उन्होंने सिद्ध किया है कि जबकि "अकाउंटेंट" (MIP) सूक्ष्म सुधार (fine-tuning) के लिए बेहतरीन है, "जासूस" (SMT) अक्सर यह जल्दी से पता लगाने के लिए बेहतर विकल्प है कि क्या कोई मिशन संभव भी है या नहीं। यह रोबोट्स के ऐसे झुंडों को बनाने की दिशा में एक महत्वपूर्ण कदम है जो वास्तविक दुनिया की आपदाओं में गतिशील रूप से काम कर सकें, और एक अच्छी तरह से समन्वित मानव बचाव दल की तरह अपनी टीम वर्क को मौके पर ही ढाल सकें।