إنشاء مساعد سائق في سباقات Formula E على Android باستخدام "حزمة تعلّم الآلة" وGemini Nano

مرحبًا.

اسمي "أليستير"، ويسعدني اليوم أن أتحدث معكم عن مشروع صغير نفّذناه العام الماضي مع "فورمولا إي".

وينضم إلينا اليوم "أولي" ليتحدّث قليلاً عمّا أنجزناه معًا.

أعمل في Google Cloud في مكتب رئيس قسم التكنولوجيا، ونحن نتطلّع دائمًا إلى محاولة تجاوز حدود ما هو ممكن على الأجهزة الجوّالة اليوم، وفي السحابة الإلكترونية، وكيف يمكنهما العمل معًا.

سأعرض لكم فيديو سريعًا يقدّم لكم لمحة عن ما قمنا به.

تتميّز سيارة الجيل الرابع بقوة 600 كيلوواط.

طاقة كهربائية بالكامل، ونظام دفع رباعي دائم

أصفه بأنّه سريع للغاية.

هل يمكننا استخدام وكيل على هاتف Pixel متصل ببيانات القياس عن بُعد الواردة من السيارة؟

عندما يصعد السائق التل في "غودوود"، سيتمكّن من التحدّث إلى السيارة.

هذا رائع!

‫Gemma، ما هي حالة إطارات سيارتي؟

يبدو ضغط الإطارات جيدًا، حوالي 1.4 بار.

هناك هاتف متصل مباشرةً بوحدة التحكّم الإلكترونية، وهو يقرأ العديد من نقاط البيانات حول ما أفعله كسائق.

هذه هي المرة الأولى التي يحدث فيها هذا في سيارة سباق.

وأعتقد أنّه ما مِن مكان أفضل لعرضها.

مرحبًا Gemma، هل نحن جاهزون؟

كل شيء جاهز في انتظارك

ما رأيناه هناك كان مشروعًا أردنا من خلاله محاولة إدخال وكيل مساعد في قمرة القيادة مع السائق.

ما نحاول فعله هنا هو توسيع حدود ما يمكن تحقيقه باستخدام الوكلاء على الأجهزة، لأنّ هذا مثال رائع على تحدٍّ صعب للغاية.

نوع التحديات التي تواجهها في سيارة السباق هو بالطبع الحرارة العالية.

تشتهر سيارات السباق بارتفاع درجة حرارتها، وهذا، كما تعلمون، جزء من أكبر التحديات.

اتصال متقطّع بالإنترنت

لذلك، نحن نقوم بذلك في مهرجان غودوود للسرعة، حيث يجتمع مئات الآلاف من عشاق رياضة السيارات لمشاهدة سباقات السيارات على التل.

وكما تتخيّل، عندما يكون هناك مئات الآلاف من الأشخاص في مكان واحد، قد تكون إمكانية الاتصال صعبة للغاية.

والبلوتوث أيضًا

على سبيل المثال، هذه السيارة هي في الأساس قفص فاراداي، لذا يمكنك تخيل نوع التحديات التي تواجهنا حتى نتمكن من الاتصال بخوذة سائق السباق.

وأخيرًا، متطلبات وقت الاستجابة المنخفض.

يقود هذا السائق بسرعة تزيد عن 200 كيلومتر في الساعة، لذا من المهم جدًا أن تكون الإجابات التي يحصل عليها من وكيل المساعد الآلي سريعة وموجزة للغاية.

ونحن مهتمون جدًا بهذا الأمر لأنّنا نعتقد أنّ الوكلاء سيصبحون منتشرين في كل مكان.

وقد بدأنا نرى ذلك بالفعل.

لم تعد موجودة في أجهزة الكمبيوتر لدينا فقط.

فهي موجودة في هواتفنا وساعاتنا ونظاراتنا ومنازلنا الذكية وحتى في سياراتنا.

لذلك، أردنا في الأساس معرفة ما يمكننا تحقيقه في هذا السيناريو الصعب.

وعندما كنا نتبادل الأفكار حول كيفية إنشاء هذا، هل ننشئ كمبيوتر صغيرًا به مسرّع صغير ليكون لدينا نموذج هناك؟

أدركنا فجأة أنّ جميع المكوّنات التي نحتاجها كانت متوفّرة بالفعل، وهي Android.

ويُعدّ Android المضيف المثالي لذلك لأنّه يتضمّن حزمة ADK، وهي حزمة تطوير الوكلاء.

هذه مكتبة رائعة تتيح لك إنشاء وكلاء مباشرةً في تطبيقك.

هناك مليارات المستخدمين، وبالتالي، كما تعلمون، هناك أشكال مختلفة يمكننا تشغيل هذا عليها بسهولة بالغة، لذا من السهل حقًا اختبار هذا وتوزيع الرمز نفسه.

"أدوات مطوّري البرامج" التي تتيح لك تصحيح الأخطاء وتجربة أشياء مختلفة والعثور على الأخطاء

بفضل الذكاء الاصطناعي على الجهاز، يتم الآن شحن هواتف Google Pixel مع وحدة معالجة Tensor (TPU) في الهاتف نفسه، وهي محسّنة للنموذج المتوفّر على الجهاز، ما يسهّل استخدام واجهات برمجة التطبيقات مثل "حزمة تعلّم الآلة" للوصول إلى نموذج فعّال للغاية.

لدينا أيضًا ميزات مثل تحويل النص إلى كلام والتعرّف على الكلام، وواجهات برمجة تطبيقات تعمل بالكامل بلا إنترنت تتيح لك الحصول على تجارب حوارية فعّالة للغاية.

وأخيرًا، بالطبع، إمكانية الاتصال.

تم تصميم الهواتف لتوفير إمكانية الاتصال، سواء من خلال شبكات الجوّال أو شبكة Wi-Fi أو وسائل أخرى.

ومن التحديات التي نواجهها أنّ الوكلاء على الأجهزة لا يمكنهم تنفيذ كل المهام، فكيف يمكنهم العمل مع الوكلاء في السحابة الإلكترونية؟

وماذا لو كان الحل هجينًا؟

ماذا لو كان بإمكان وكيل يعيش في هاتف أن يتحدث مباشرة إلى وكيل في السحابة الإلكترونية ليتمكن من تنفيذ إجراءات أكثر تعقيدًا؟

على سبيل المثال، لنفترض أنّ السائق يريد معرفة مركزه في السباق.

السيارة نفسها لن تعرف مركزها في السباق، ولكن قد يعرفه وكيل في السحابة الإلكترونية.

ولدينا بروتوكول يُسمّى "من وكيل إلى وكيل"، ما يعني أنّه يمكنكم إنشاء وكلاء على الأجهزة الطرفية وفي السحابة الإلكترونية وجعلهم يتواصلون مع بعضهم البعض لتنفيذ إجراءات أكثر تعقيدًا.

فكيف أنشأناه؟

لذا، سأطلعكم على نوع من مكونات هذا النظام.

لنبدأ من الحزام.

الآن، الإطار هنا هو في الأساس تطبيق Android يشغّل حزمة Agent Developer Kit لنظام التشغيل Android.

والجزء الثاني هو نموذج.

تحتاج إلى نموذج لتشغيلها، وبالنسبة إلينا، كنّا نستخدم Gemini Nano من خلال "حزمة تعلّم الآلة"، وهو نموذج فعّال للغاية على الجهاز فقط.

بعد ذلك، البيانات.

سيتحدث "أولي" عن هذا الموضوع بعد قليل، ولكن لديك البيانات الواردة من السيارة، وأيضًا، من المحتمل، ميزة التعرّف على الكلام من السائق.

وأخيرًا، هناك أيضًا الإجراءات التي يمكن للوكيل تنفيذها.

قد يكون ذلك من خلال ميزة تحويل النص إلى كلام للتمكّن من التحدّث إلى السائق وطرح أسئلة متابعة أو تقديم المعلومات المطلوبة، أو كما ذكرنا سابقًا، من خلال التواصل بين الوكلاء مع وكيل في السحابة الإلكترونية لتنفيذ بعض الإجراءات الأكثر تعقيدًا.

أودّ الآن دعوة "أولي" إلى المنصة ليتحدّث قليلاً عن كيفية تحقيق ذلك من خلال بطولة "فورمولا إي".

شكرًا، أليستر.

لدينا الآن المكوّنات، ولكن يبقى الجزء الأصعب: كيف ندمج وكيل الذكاء الاصطناعي في سيارة "فورمولا إي"؟

يبدأ الأمر هنا في وحدة التحكّم في المركبة (VCU).

الآن، كل أداة استشعار وكل مكوِّن في السيارة يرسل تقارير إليها عبر ما يسمى شبكة التحكّم النطاقي (CAN).

وتُنشئ السيارة آلاف النقاط من بيانات القياس عن بُعد في الثانية، مثل السرعة والتسارع والخانق والكبح والمزيد.

لذا، من أجل توصيل-- لذا، من أجل قراءة هذا القياس عن بُعد، ما قررنا القيام به هو توصيل Raspberry Pi مباشرة في VCU للسيارة عبر اتصال CAN هذا.

الآن، يقوم Raspberry Pi ببعض الأشياء المختلفة.

أولاً، يفكّ ترميز الإشارات الأولية، ويحوّلها، ويقلّل معدّل عيّناتها إلى حوالي 10 هرتز، وهو ما يوفّر معلومات كافية لمساعد السائق.

بعد ذلك، ينشر Raspberry Pi هذه البيانات المحسّنة عبر MQTT إلى هاتف Pixel 10 Pro في مقصورة السيارة.

وهذا أحد المدخلات التي يمكن أن يقبلها التطبيق الذي يستضيف تطبيق الوكيل.

ثانيًا، ميزة "التعرّف على الكلام" في Android.

لذا، عندما يتحدث السائق، يحوّل التطبيق الإدخال إلى نص، ويتمكّن Gemini Nano من تحليل هذين الإدخالين.

يمكن للوكيل الآن اتخاذ قرارَين: أولاً، يمكنه استخدام محرّك تحويل النص إلى كلام في Android للردّ على السائق.

ثانيًا، كما ذكر "أليستر" سابقًا، يمكنه التواصل مع الوكيل السحابي من خلال بروتوكول A2A.

الآن، في هذا الصدد، يكون تدفق الوكيل بسيطًا للغاية: قل الكلمة الرئيسية، في هذه الحالة "مرحبًا، Gemma"، واطرح سؤالاً، واحصل على إجابة.

يظلّ الوكيل يستمع إليك لمدة 5 ثوانٍ تقريبًا بعد ذلك، ما يتيح لك طرح سؤال متابعة بدون الحاجة إلى البدء من جديد، تمامًا مثل التحدّث إلى مهندس سباق حقيقي.

التطبيق هو أيضًا وكيل متعدد الجولات، ما يعني أنّه يمكنه الوصول إلى سجلّ المحادثات ليكون أكثر تفاعلاً.

لذا، قد تتوقع أن تبدو التعليمة البرمجية لهذا معقدة بعض الشيء، أليس كذلك؟

حسنًا، لقد اتضح أنّ الأمر بسيط جدًا.

تستدعي الأسطر القليلة الأولى onDeviceModel باستخدام "حزمة تعلّم الآلة" وتغلفه كـ Gemini Nano.

val generativeModel: GenerativeModel = Generation.getClient()
val onDeviceModel = GenaiPrompt.create(
    generativeModel = generativeModel,
    name = "gemini-nano",
)
val agent = LlmAgent(
    name = "race_engineer",
    model = onDeviceModel,
    staticInstruction = /* System prompt */,
    instruction = Instruction {
        /* Dynamic context */
    },
    tools = listOf(
        /* Custom tools */
    )
)

بعد ذلك، نحدّد الوكيل باستخدام ADK.

أولاً، يجب تسمية المساعد وإدخال نوعَين من التعليمات: التعليمات الثابتة، وهي تحدّد شخصيته وهويته.

ويمكن أن يشمل ذلك أشياء مثل كيفية التحدث إلى السائق وبعض المعلومات حول مضمار السباق.

والثاني هو التعليمات الديناميكية.

يتم الآن إنشاء هذا الملخّص مع كل طلب بحث يتضمّن أحدث ملخّص للقياس عن بُعد، ليكون الوكيل على عِلم دائمًا بما يفعله السائق في أي وقت.

ويتضمّن أيضًا سجلّ المحادثة الحالية، كما ذكرنا سابقًا.

بالإضافة إلى ذلك، نحدّد أيضًا بعض الأدوات، مثل منحه إمكانية الوصول إلى بيانات الجلسات السابقة، وإمكانية التواصل مع وكيل السحابة الإلكترونية، وإمكانية التواصل مع السائق باستخدام ميزة "تحويل النص إلى كلام".

والآن، لنلقِ نظرة على عرض توضيحي سريع للوكيل أثناء عمله على أجهزة المحاكاة في مكتب "فورمولا إي".

‫Gemma، هل أسلوب توجيهي للسيارة عدواني؟

سلس ومدروس

كانت زاوية الانعطاف القصوى 48 درجة، وكنت تحرك العجلة بمعدل 11 درجة في الثانية في المتوسط.

‫Gemma، ما هو الحد الأقصى لقوة التسارع التي أتعرّض لها؟

بلغت ذروة قوة الجاذبية 2.2 G عند المنعطفات.

‫Hey Gemma، كيف كان أدائي في الركض؟

أداء قوي يا "دان".

السرعة القصوى 306 كم/ساعة، بمتوسط 186 على مدار 35 ثانية.

كنت تقود بأقصى سرعة في %58 من الوقت، وبلغت ذروة التسارع 2.2 G.

وهذا كل ما في الأمر.

هذا هو Gemini Nano على هاتف يتحدث إلى سائق، ويجيب عن أسئلته في الوقت الفعلي.

هناك فرق كبير بين جهاز محاكاة السباق وسيارة "فورمولا إي".

فكيف جمعنا كل هذه العناصر معًا؟

أولاً، كان علينا الذهاب إلى شركة Spark Racing Technology في باريس، حيث يتم تصنيع سياراتنا.

هذه صورتي على اليسار وأنا أربط Raspberry Pi بوحدة التحكّم في السيارة (VCU) الفعلية لسيارة Formula E.

كل ما أنشأناه حتى الآن كان يعتمد على بيانات تمت محاكاتها وتمت إعادة تشغيلها من جلسة اختبار، لذلك لم نكن نعرف حقًا ما إذا كان سيعمل مع الشيء الحقيقي.

لذا قمنا بتوصيله، وتشغيله، وانتظرنا، وانتظرنا أكثر قليلاً، وأخيرًا بدأ القياس عن بُعد في الظهور على الجهاز، مما يثبت أن البيانات كانت تتحرك عبر النظام كما توقعنا.

على اليمين، يمكنك رؤية النظام النهائي، ويمكنك أن ترى أن الهاتف قد تم تنفيذه بالفعل في قمرة القيادة، بجوار المكان الذي سيجلس فيه السائق مباشرة.

لذا، كنا جميعًا مستعدين لسباق "غودوود".

إذًا، ماذا حدث في ذلك اليوم؟

هل تتذكر التحديات الأربعة التي تحدّث عنها "أليستر" سابقًا؟

وقد اختبرت حلبة "غودوود" اثنتَين منها.

أولاً، الحرارة.

في بريطانيا، نخطّط عادةً لأي طقس باستثناء الطقس المشمس.

لذا، بطبيعة الحال، ما حصلنا عليه كان أحد أكثر الأسابيع حرارة على الإطلاق، في منتصف موجة الحر.

هذا هو الوقت المثالي لوضع جهاز كمبيوتر داخل سيارة "فورمولا إي".

ولكن المفاجأة هي أنّ

كان الهاتف في الواقع على ما يرام.

لم يتأثر Android على الإطلاق.

تبيّن أنّ Raspberry Pi هو الذي واجه أكبر صعوبة.

وبما أنّه لم يكن بإمكاننا توصيله مباشرةً بالسيارة، كان علينا استخدام جهاز يُعرف باسم "مصدر الطاقة غير المنقطع" (UPS)، وهو عبارة عن مجموعة من البطاريات الملتصقة بالجزء السفلي من جهاز Pi.

ولكن لحسن الحظ، تمكّنا من حلّ هذه المشكلة من خلال إعادة شحنها بشكل متقطّع طوال اليوم، وبدون ذلك، ربما لم تكن السيارة لتصعد ذلك التل بدون وكيل ذكاء اصطناعي على الإطلاق.

بعد ذلك، تم إطلاق البلوتوث.

في تلك المرحلة، لم نكن قد اختبرنا الخوذة التي يرتديها السائق، والتي تتصل بالتطبيق عبر البلوتوث.

وكان ذلك يمثّل تحديًا بعض الشيء.

لاختبار ذلك، جلسنا على العشب، ويبدو أنّنا نقضي وقتًا ممتعًا، أليس كذلك؟

أخرجنا أجهزة الكمبيوتر المحمولة، ونجري محادثة لطيفة.

في الواقع، كانت تلك الفترة من أكثر الفترات إرهاقًا في مسيرتي المهنية حتى الآن.

كنا نحاول جاهدين الحصول على هذا الرمز للعب بشكل جيد وتوصيل خوذة البلوتوث بالتطبيق قبل أن يصعد السائق إلى التل في فترة ما بعد الظهر.

ولكن بفضل بعض الإصلاحات العاجلة في اللحظات الأخيرة وأدوات تصحيح الأخطاء الرائعة في Android، تمكّنا من حلّ المشكلة في الوقت المناسب، وصعدت السيارة التلّ مع عمل وكيل الذكاء الاصطناعي بشكل رائع.

والآن، سأعيد الكلمة إلى "أليستير" الذي سيتحدث معنا أكثر عن الدروس المستفادة من المشروع.

شكرًا.

شكرًا لك يا "أولي".

إذًا، ما هي الدروس المستفادة من هذا المشروع؟

أولاً، يُعدّ Android مضيفًا مثاليًا لوكلائك.

أشجّعكم بشدة على الاستفادة من مرونة Android وواجهات برمجة التطبيقات المتاحة لكم والنماذج على الجهاز فقط وحزمة ADK.

جرِّبها وستفاجئك التجارب الرائعة التي يمكنك الحصول عليها من هذه الألعاب البسيطة.

لا تزال مشكلة التكامل موجودة.

من المحتمل أن معظم الأشخاص في هذه الغرفة قد مروا بهذا في مرحلة ما من حياتهم المهنية.

تقوم ببناء جميع المكونات الفرعية بشكل منفصل، ثم عندما تأتي لتوصيلها معًا في النهاية، لا يعمل شيء ما بشكل صحيح.

وكانت خوذة السباق التي يرتديها السائق بهذا الشكل تمامًا.

ولكن لحسن الحظ، تمكّنا من إصلاحها في اليوم نفسه، وهذا يثبت حقًا أنّ الاختبار لا يزال بالغ الأهمية.

وأخيرًا، Gemini Nano.

كان Gemini Nano بطلاً حقيقيًا في هذه الحالة.

إنّه نموذج فعّال للغاية، ويعمل بسرعة كبيرة على جهازك ويمكنه تنفيذ مهام معقّدة جدًا، ولكنّه لا يفعل ذلك على الفور.

هناك بعض التفكير الحقيقي وراء ذلك.

عليك استخدام هندسة الطلبات.

عليك اختباره.

عليك التفكير في الطريقة التي تريد بها تقديم التعليمات الديناميكية مقابل التعليمات الثابتة.

عليك التفكير في الأدوات التي ستوفّرها له وكيفية توجيهه بأفضل شكل ممكن لتنفيذ هذه المهمة.

ولكن من خلال إجراء الاختبارات والتقييمات المناسبة، يمكنك الاستفادة كثيرًا من نموذج مثل Gemini Nano على الجهاز مباشرةً.

شكرًا جزيلاً لكم جميعًا.

سنكون في الجناح لاحقًا، لذا يمكنك الانضمام إلينا وطرح بعض الأسئلة.