IoT-তে AI-এর নতুন যুগ: ESP-Claw এবং Local LLM নিয়ে আমার রিয়েল-লাইফ এক্সপেরিয়েন্স

এম্বেডেড সিস্টেম নিয়ে যারা কাজ করেন, তারা জানেন মাইক্রোকন্ট্রোলারের দুনিয়াটা কতটা নিয়মতান্ত্রিক। একটি সাধারণ ESP32 বা Arduino বোর্ডে আমরা মূলত C/C++ দিয়ে ফিক্সড লজিক বা if-else কন্ডিশন লিখে থাকি। হার্ডওয়্যার ঠিক ততটুকুই করে, যতটুকু তাকে কোডে বলে দেওয়া হয়। সেন্সর থেকে ডেটা নেওয়া, নির্দিষ্ট থ্রেশহোল্ড পার হলে একটি রিলে বা LED অন করা—এসবই চলে আমাদের ঠিক করে দেওয়া গণ্ডির ভেতর।

কিন্তু একবার ভেবে দেখুন তো, যদি এমন হয় যে আপনার মাইক্রোকন্ট্রোলারটি শুধু ডেটা রিড করছে না, বরং মানুষের মতো করে সেই ডেটা ‘বুঝতে’ পারছে? যদি সে সেন্সরের ডেটা বিশ্লেষণ করে নিজেই সিদ্ধান্ত নিতে পারে যে এখন কী করা উচিত?

ঠিক এই অভাবনীয় কনসেপ্টটিকেই বাস্তবে রূপ দিচ্ছে Espressif-এর নতুন এবং বৈপ্লবিক ফ্রেমওয়ার্ক—ESP-Claw।

আজকের এই লেখায় আমি কোনো থিওরিটিক্যাল আলোচনা করবো না। বরং শেয়ার করবো ESP-Claw সেটআপ করতে গিয়ে আমার সারাদিনের একটি রিয়েল-লাইফ টেকনিক্যাল জার্নির কথা। কীভাবে ক্লাউড API-এর রেট লিমিট আর টোকেন সাইজের ধাক্কা খেয়ে আমি পুরো সিস্টেমটিকে ইন্টারনেটের বাইরে নিয়ে এলাম, এবং সম্পূর্ণ অফলাইনে নিজের ল্যাপটপের ‘Local AI’ ব্যবহার করে একটি ESP32-S3 বোর্ডকে কন্ট্রোল করলাম—সেই গল্পই ধাপে ধাপে তুলে ধরবো।

কোর মেকানিজম: পর্দার আড়ালে ESP-Claw আসলে কীভাবে কাজ করে?

ESP-IDF পরিবেশে কাজ করার সুবাদে হার্ডওয়্যার লেভেলের আর্কিটেকচার নিয়ে ঘাঁটাঘাঁটি করার সুযোগ আমার বরাবরই হয়। ESP-Claw-এর আর্কিটেকচার এনালাইসিস করে আমি যা দেখলাম, তা রীতিমতো মাস্টারপিস। এটি শুধু হার্ডওয়্যার আর AI-এর মধ্যে ডেটা পাস করে না, বরং পুরো সিস্টেমটাকে একটি ‘স্মার্ট ইকোসিস্টেম’-এ পরিণত করে।

পর্দার আড়ালে এর মূল মেকানিজমকে তিনটি প্রধান ভাগে ভাগ করা যায়:

ক. হার্ডওয়্যারকে ‘টুলস’ (Tools) হিসেবে রূপান্তর: সাধারণত আমরা পিন হাই/লো বা PWM জেনারেট করার জন্য হার্ডকোড করে থাকি। কিন্তু ESP-Claw এম্বেডেড পেরিফেরালগুলোকে (যেমন: GPIO, LEDC, I2C) লার্জ ল্যাঙ্গুয়েজ মডেলের (LLM) কাছে “ফাংশন কলিং” বা “টুলস” হিসেবে উপস্থাপন করে। ধরুন, আপনি টেলিগ্রামে আপনার বোর্ডকে মেসেজ দিলেন, “ল্যাবের লাইটটা একটু কমিয়ে দাও”। ESP-Claw তখন এই ইনস্ট্রাকশন এবং হার্ডওয়্যারের বর্তমান স্ট্যাটাস একটি সুনির্দিষ্ট JSON ফরম্যাটে কনভার্ট করে AI-এর কাছে পাঠায়। AI বুঝতে পারে যে তাকে PWM (LEDC) কন্ট্রোল করার টুলটি ব্যবহার করতে হবে এবং সে সেই অনুযায়ী একটি JSON কমান্ড রিটার্ন করে, যা বোর্ড সাথে সাথে এক্সিকিউট করে।

খ. ইভেন্ট রাউটার (The Nervous System): পুরো ফ্রেমওয়ার্কটির স্নায়ুতন্ত্র হলো এর claw_event_router। এটি যেকোনো এক্সটার্নাল ইভেন্ট (যেমন Telegram থেকে আসা মেসেজ বা কোনো সেন্সরের সিগন্যাল) রিসিভ করে। এরপর রাউটিং রুলস চেক করে সেটি claw_core-এ পাঠায়। প্রসেসিং শেষে রিপ্লাই বা কমান্ডটি আবার সঠিক চ্যানেলে (যেমন টেলিগ্রাম চ্যাটে) ইউজারের কাছে ফেরত পাঠায়। এই পুরো প্রসেসটি অত্যন্ত ফাস্ট এবং অ্যাসিঙ্ক্রোনাসলি (asynchronously) কাজ করে।

গ. মেমরি ম্যানেজমেন্ট (The Hidden Beast): ESP-Claw-এর সবচেয়ে চমকপ্রদ এবং একইসাথে সবচেয়ে ‘হেভিওয়েট’ ফিচার হলো এর মেমরি ম্যানেজমেন্ট বা claw_memory। এটি শুধু বর্তমান মেসেজ প্রসেস করে না, বরং ইউজারের সাথে হওয়া কনভার্সেশনের একটি প্রোফাইল মেমরি (Profile Memory) এবং লং-টার্ম মেমরি (Long-term Memory) তৈরি করে রাখে।

আজকের টেস্টিংয়ে সিরিয়াল মনিটরের লগ ডিবাগ করতে গিয়ে আমি বিশাল এক আবিষ্কার করি। একটি সাধারণ মেসেজের রিপ্লাই দেওয়ার জন্যও ESP-Claw ব্যাকগ্রাউন্ডে এর ‘Skills List’ এবং ‘Tools’-এর বিশাল ডেটাবেস লোড করে। সব মিলিয়ে একটি সিঙ্গেল রিকোয়েস্টেই এটি প্রায় ১২,০০০ টোকেনের একটি পেলোড (Payload) সার্ভারে পাঠায়! আর এই বিশাল মেমরি কনটেক্সটই মূলত ফ্রেমওয়ার্কটিকে এত স্মার্ট করে তুলেছে, যাতে সে পূর্বের আলোচনার সূত্র ধরে হার্ডওয়্যারকে নিখুঁতভাবে গাইড করতে পারে।

ক্লাউড API-এর ধাক্কা: অপ্রত্যাশিত বটলনেক এবং একটি বড় আবিষ্কার

যেকোনো এআই প্রজেক্টের শুরুতে আমাদের প্রথম পছন্দ থাকে ক্লাউড API। আমার প্ল্যানও ছিল Google Gemini বা Groq API ব্যবহার করে প্রজেক্টটি খুব দ্রুত রান করিয়ে ফেলা। কিন্তু হার্ডওয়্যারের রিয়েলিটি যে এতোটা কঠিন হবে, তা শুরুতে বুঝতে পারিনি। এখানেই আমি প্রথম বড় ধাক্কাটি খাই।

প্রথমে সেটআপ করলাম Google Gemini (gemini-2.0-flash)। কিন্তু রান করার সাথে সাথেই সিরিয়াল মনিটরে এরর আসতে শুরু করলো: HTTP 429 (Too Many Requests / Quota Exceeded)। আমি অবাক হলাম, কারণ ড্যাশবোর্ডে দেখাচ্ছে আমার কোটা একদম ফুল! ডিবাগ করতে গিয়ে একটি দারুণ জিনিস শিখলাম। ESP-Claw যখন কোনো মেসেজ পায়, তখন সে একইসাথে দুটি আলাদা API রিকোয়েস্ট (Concurrent requests) সার্ভারে পাঠায়—একটি ইউজারের মেমরি বা প্রোফাইল আপডেট করার জন্য (Auto Extract Memory), অন্যটি রিপ্লাই দেওয়ার জন্য। জেমিনির ফ্রি টিয়ারে একসাথে এমন একাধিক রিকোয়েস্ট এলাউ করে না বলেই এই 429 এররটি আসছিল।

এরপর আমি সিদ্ধান্ত নিলাম Groq API-তে শিফট করার, কারণ এর রেসপন্স টাইম মিলি-সেকেন্ডে এবং এটি এম্বেডেড ডিভাইসের জন্য দারুণ ফাস্ট। কিন্তু সেখানে অপেক্ষা করছিল আরও বড় একটি সারপ্রাইজ!

কানেকশন সফল হওয়ার পর যখন টেলিগ্রাম থেকে মেসেজ দিলাম, তখন লগে নতুন এরর আসলো: HTTP 413: Request too large। Groq-এর ফ্রি টিয়ারে প্রতি মিনিটে ৬,০০০ টোকেন (6000 TPM) প্রসেস করার লিমিট থাকে। আমি সিরিয়াল মনিটরের লগ ঘেঁটে দেখলাম, ESP-Claw আসলে কতগুলো টোকেন পাঠাচ্ছে। লগ দেখে আমার তো চোখ কপালে ওঠার জোগাড়!

একটি সাধারণ “Hello” মেসেজের রিপ্লাই দেওয়ার জন্যও ESP-Claw ব্যাকগ্রাউন্ডে পাঠায়:

• Skills List: 3473 টোকেন
• Tools: 8015 টোকেন
• Profile Memory: 1269 টোকেন

সব মিলিয়ে একটি সিঙ্গেল রিকোয়েস্টেই প্রায় ১২,২২৪ টোকেনের একটি বিশাল পেলোড (Payload) যাচ্ছে! কোনো সাধারণ ফ্রি ক্লাউড API-এর পক্ষেই এই বিশাল কনটেক্সট উইন্ডো কোনো লিমিটেশন ছাড়া প্রসেস করা সম্ভব নয়।

লোকাল AI (Ollama)-এর ম্যাজিক: সম্পূর্ণ অফলাইন এবং আনলিমিটেড সেটআপ

ক্লাউডের রেট লিমিট আর টোকেন সাইজের এই বিশাল দেয়ালের সামনে দাঁড়িয়ে বুঝতে পারলাম, থার্ড-পার্টি সার্ভারের ওপর নির্ভর করে এই প্রজেক্ট বেশিদূর নেওয়া যাবে না। আমাকে পুরো এআই ব্রেইনটাকে নিজের কন্ট্রোলে নিয়ে আসতে হবে। শুরু হলো প্রজেক্টের সবচেয়ে এক্সাইটিং ফেজ—সিস্টেমটিকে সম্পূর্ণ অফলাইনে, অর্থাৎ লোকাল হোস্টে নিয়ে আসা।

আমি আমার ল্যাপটপে Ollama ইনস্টল করলাম এবং হার্ডওয়্যারের ইনস্ট্রাকশন ফলো করার জন্য অত্যন্ত ফাস্ট ও লাইটওয়েট একটি মডেল llama3.2:1b (১ বিলিয়ন প্যারামিটার) রান করালাম। কিন্তু এখানে একটি বড় নেটওয়ার্কিং চ্যালেঞ্জ ছিল। ডিফল্টভাবে Ollama শুধু পিসির ভেতরেই (Localhost বা 127.0.0.1) সীমাবদ্ধ থাকে। বাইরের কোনো ডিভাইস (যেমন আমার ESP32-S3) এতে কানেক্ট করতে পারে না।

এই সমস্যার সমাধানে আমি একটি চমৎকার ‘নেটওয়ার্কিং ট্রিক’ ব্যবহার করলাম:

• প্রথমে ল্যাপটপ থেকে একটি Mobile Hotspot চালু করে আমার ESP32-S3 বোর্ডটিকে সেই হটস্পটে কানেক্ট করালাম। এর ফলে ল্যাপটপ এবং বোর্ড একই লোকাল নেটওয়ার্কে চলে আসলো (হটস্পটের আইপি পেলাম: 192.168.137.1)।
• এরপর ল্যাপটপের PowerShell ওপেন করে ব্যাকগ্রাউন্ড সার্ভার বন্ধ করলাম এবং একটি এনভায়রনমেন্ট ভ্যারিয়েবল ডিক্লেয়ার করলাম: $env:OLLAMA_HOST=“0.0.0.0”।
• সবশেষে ollama serve কমান্ড দিয়ে সার্ভারটি রান করাতেই সেটি ল্যাপটপের গণ্ডি পেরিয়ে পুরো নেটওয়ার্কের জন্য উন্মুক্ত হয়ে গেল (লগে দেখলাম: Listening on [::]:11434)!

এবার ESP-Claw-এর ওয়েব প্যানেলে গিয়ে LLM URL হিসেবে শুধু http://192.168.137.1:11434/v1 বসিয়ে দিলাম।

টেলিগ্রাম বট থেকে যখন মেসেজ দিলাম, ল্যাপটপের টার্মিনালে সরাসরি রিকোয়েস্ট হিট করলো! ক্লাউডের কোনো লিমিটেশন, কোটা শেষ হওয়ার ভয় বা ইন্টারনেটের ল্যাগ ছাড়াই ১২ হাজার টোকেনের সেই বিশাল প্রম্পট সরাসরি আমার ল্যাপটপে প্রসেস হতে শুরু করলো। ESP-Claw সফলভাবে কনটেক্সট লোড করে রিপ্লাই জেনারেট করলো এবং লগে ভেসে উঠলো সেই কাঙ্ক্ষিত মেসেজ: err=ESP_OK output=reply already sent to user।

ক্লাউড থেকে বেরিয়ে এসে হার্ডওয়্যারকে লোকাল মেশিনের ব্রেইন দিয়ে স্মার্ট করে তোলার এই মুহূর্তটি ছিল একজন ডেভেলপারের জন্য সত্যিই দারুণ রোমাঞ্চকর!

বর্তমান সীমাবদ্ধতা: হার্ডওয়্যারের রিয়েলিটি চেক এবং টাইমআউটের লড়াই

লোকাল হোস্টে সিস্টেম রান করানোর পর মনে হচ্ছিল হয়তো সব সমস্যার সমাধান হয়ে গেছে। কিন্তু হার্ডওয়্যারের রিয়েলিটি যে এতোটা সহজ নয়, তা বুঝতে পারলাম কিছুক্ষণ পরেই।

সবকিছু পারফেক্টলি কাজ করলেও, টেলিগ্রামে মেসেজ দেওয়ার পর রিপ্লাই আসতে অনেক সময় লাগছিল। এক পর্যায়ে দেখলাম, তিন মিনিট পার হওয়ার পর টেলিগ্রামে নতুন একটি এরর মেসেজ আসলো: HTTP request failed: ESP_ERR_HTTP_EAGAIN।

লগ ডিবাগ করে দেখলাম, এখানে একটি নতুন এবং বেশ লজিক্যাল চ্যালেঞ্জ তৈরি হয়েছে—টাইমআউট (Timeout)।

ESP-Claw এর পাঠানো সেই ১২-১৩ হাজার টোকেনের বিশাল ডেটা আমার ল্যাপটপের সাধারণ ইন্টেল i5 প্রসেসরে (CPU) প্রসেস হতে প্রায় ২ থেকে ৩ মিনিট সময় নিচ্ছিল। কিন্তু ESP32-S3 বোর্ডের একটি নির্দিষ্ট ধৈর্য বা HTTP Timeout লিমিট আছে। বোর্ডটি সার্ভারের রিপ্লাইয়ের জন্য অপেক্ষা করতে করতে যখন দেখে যে অনেকক্ষণ হয়ে গেছে, তখন সে নিজেই কানেকশনটি কেটে দেয়।

এর থেকে দুটি পরিষ্কার টেকনিক্যাল লেসন পেলাম:

1. প্রম্পট অপটিমাইজেশনের অভাব: ESP-Claw ফ্রেমওয়ার্কটির প্রম্পট ইঞ্জিনিয়ারিং এখনো প্রাথমিক পর্যায়ে আছে। প্রতিটি মেসেজের সাথে পুরো ‘Tools’ এবং ‘Skills’ লিস্ট পাঠানোটা সাধারণ এম্বেডেড ডিভাইসের জন্য বাস্তবসম্মত নয়। ওয়েব প্যানেল থেকে অপ্রয়োজনীয় টুলস বা মেমরি এক্সট্রাকশন ডিজেবল করে কনটেক্সট সাইজ কমিয়ে আনাটা অত্যন্ত জরুরি।
2. শক্তিশালী হার্ডওয়্যারের প্রয়োজনীয়তা: লোকাল এআই (Local AI) দিয়ে রিয়েল-টাইম (মিলি-সেকেন্ডে) হার্ডওয়্যার কন্ট্রোল করতে চাইলে সাধারণ CPU-এর বদলে একটি ডেডিকেটেড গ্রাফিক্স কার্ড (GPU) বা VRAM-সমৃদ্ধ পিসি থাকাটা আবশ্যক।

ভবিষ্যৎ সম্ভাবনা: এডুকেশন, রিসার্চ এবং ইন্ডাস্ট্রিয়াল ইমপ্যাক্ট

কিছু বাগ বা টাইমআউটের সমস্যা থাকলেও, ESP-Claw এবং লোকাল এআইয়ের এই কনসেপ্টটি যে ভবিষ্যতের জন্য একটি গেম-চেঞ্জার, তাতে কোনো সন্দেহ নেই।

বিশেষ করে ‘ক্ষুদে ইঞ্জিনিয়ার একাডেমি’-এর মতো উদ্যোগে, যেখানে স্কুলপড়ুয়া শিক্ষার্থীদের হাতে-কলমে রোবটিক্স এবং বেসিক ইলেক্ট্রনিক্স শেখানো হয়, সেখানে এটি দারুণ ইমপ্যাক্ট ফেলতে পারে। ক্লাসরুম বা ল্যাবে অনেক সময়ই নিরবচ্ছিন্ন বা হাই-স্পিড ইন্টারনেট থাকে না। ক্লাউড API-এর রেট লিমিট শেষ হয়ে যাওয়ার ভয়েও থাকতে হয়। কিন্তু একটি ল্যাপটপে Ollama সার্ভার রান করিয়ে পুরো ল্যাবের হার্ডওয়্যারগুলোকে যদি অফলাইনে এআইয়ের সাথে কানেক্ট করা যায়, তবে শিক্ষার্থীরা সরাসরি তাদের তৈরি রোবট বা প্রোজেক্টের সাথে কথা বলতে পারবে! ইন্টারনেট ছাড়াই এআই তাদের হার্ডওয়্যার লজিক বুঝতে এবং কন্ট্রোল করতে সাহায্য করবে।

ইন্ডাস্ট্রিয়াল লেভেলেও এর সম্ভাবনা বিশাল। ফ্যাক্টরি অটোমেশন বা স্মার্ট ফার্মিংয়ে এমন অনেক জায়গা থাকে যেখানে ডেটা সিকিউরিটির জন্য ইন্টারনেট ব্যবহার করা যায় না (Air-gapped systems)। সেখানে এমন এজ-লেভেল (Edge-level) লাইটওয়েট ল্যাঙ্গুয়েজ মডেল এবং ESP-Claw-এর মতো ফ্রেমওয়ার্ক ব্যবহার করে সম্পূর্ণ প্রাইভেট ও স্মার্ট ইকোসিস্টেম তৈরি করা সম্ভব।

হার্ডওয়্যারের নতুন দিগন্ত

Espressif-এর ESP-Claw এখনো তার আর্লি স্টেজে (v0.2) রয়েছে। স্বাভাবিকভাবেই এতে কিছু বাগ আছে, মেমরি ম্যানেজমেন্ট আরও অপটিমাইজ করার সুযোগ আছে। কিন্তু এর পেছনের ভিশনটি শতভাগ সলিড।

মাইক্রোকন্ট্রোলার এখন আর শুধু if-else কন্ডিশনের দাস নয়। ক্লাউড বা লোকাল এলএলএম (LLM)-এর সাথে যুক্ত হয়ে এটি এখন ইনস্ট্রাকশন বুঝতে পারে, ডিসিশন নিতে পারে এবং হার্ডওয়্যারকে স্মার্টলি অপারেট করতে পারে। আজকের এই সারাদিনের টেস্টিং, 429 রেট লিমিটের ধাক্কা, 413 টোকেন ওভারফ্লো এবং সবশেষে লোকাল সার্ভারের মাধ্যমে সফলভাবে রিপ্লাই পাওয়ার জার্নিটি আমাকে অন্তত এই বিশ্বাসটুকু দিয়েছে—এম্বেডেড সিস্টেমের ভবিষ্যৎ শুধু কোড লেখার মধ্যেই সীমাবদ্ধ থাকবে না, বরং এআইকে হার্ডওয়্যারের সাথে কথা বলতে শেখানোর ওপরই নির্ভর করবে।

ক্লাউড থেকে বেরিয়ে এসে হার্ডওয়্যারকে লোকালি স্মার্ট করে তোলার এই যাত্রা কেবল শুরু। আমি আমার নতুন এবং শক্তিশালী পিসিতে এটি নিয়ে আরও গভীর রিসার্চ এবং এক্সপেরিমেন্ট চালিয়ে যাবো। সেই আপডেটগুলো আপনাদের সাথে শেয়ার করার অপেক্ষায় রইলাম।