خودرو مسابقهای محیطی چالشبرانگیز با سرعت بالا، گرما، و محدودیتهای دورسنجی است. چگونه یک عامل دروندستگاهی میتواند به پردازش دادههای همزمان خودرو برای کاربردهای ورزشی و مهندسی کمک کند؟
این جلسه فنی یک معماری ترکیبی آزمایشی را بررسی میکند که سختافزار لبه و عاملهای ابری را ترکیب میکند. ما یک اثبات مفهوم پژوهشی را بااستفاده از Raspberry Pi برای جاریسازی دورسنجی گذرگاه CAN، یک تلفن Pixel که عامل مکالمهای دروندستگاهی با پشتیبانی ML Kit و Gemini Nano را اجرا میکند، و یک اتصال ابری عاملبهعامل (A2A) برای گردشهای کاری پساز مسابقه بررسی خواهیم کرد.
آوانویسی
سلام.
نام من الستر است و امروز بسیار خوشحالم که درباره پروژهای که سال گذشته با فرمول E انجام دادیم، با شما صحبت میکنم.
و من الی را اینجا دارم تا امروز به ما بپیوندد تا کمی درباره کاری که با هم انجام دادیم صحبت کنیم.
بنابراین، در-- من در Google Cloud در دفتر مدیر ارشد فناوری کار میکنم، و ما اغلب بهدنبال تلاش و فراتر رفتن از مرزهای آنچه امروز در تلفن همراه و Cloud ممکن است، و اینکه چگونه میتوانند باهم کار کنند، هستیم.
میخواهم ویدیو کوتاهی به شما نشان دهم که مقدمهای بر کارهایی است که انجام دادیم.
خودرو نسل ۴ دارای ۶۰۰ کیلووات قدرت مسابقهای است.
تمام برقی، تمام چرخها متحرک دائمی.
من آن را خیلی سریع توصیف میکنم.
آیا میتوانیم از عاملی در تلفن Pixel استفاده کنیم که به دادههای دورسنجی که از خودرو میآید متصل است؟
وقتی راننده در گودوود از تپه بالا میرود، میتواند با خودرو صحبت کند.
خیلی جالب است!
سلام Gemma، لاستیکهایم چطورند؟
فشار تایرها خوب بهنظر میرسد، حدود ۱٫۴ بار.
تلفنی وجود دارد که مستقیماً به ECU متصل است و نقاط داده بسیار زیادی را از آنچه من بهعنوان راننده انجام میدهم میخواند.
این اولینبار است که چنین اتفاقی در خودرو مسابقه میافتد.
فکر میکنم واقعاً جای بهتری برای نمایش آن وجود ندارد.
سلام Gemma، آمادهایم؟
هروقت آماده بودید من هم آمادهام.
بنابراین، آنچه در آنجا دیدیم پروژهای بود که میخواستیم سعی کنیم یک عامل کمکراننده را به همراه راننده به کابین خلبان بیاوریم.
و اساساً، آنچه ما در اینجا تلاش میکنیم انجام دهیم، فراتر رفتن از مرزهای ممکن با عاملها در لبه است، زیرا این یک نمونه عالی از یک چالش واقعاً دشوار است.
نوع چالشهایی که در خودرو مسابقهای میبینید، مشخصاً گرمای زیاد است.
خودروهای مسابقهای بهخاطر داغ شدن معروف هستند و این، میدانید، بخشی از بزرگترین چالش است.
اتصال ناپایدار.
بنابراین، ما درواقع این کار را در «جشنواره سرعت گودوود» انجام میدهیم، جایی که، میدانید، صدها هزار طرفدار ورزشهای موتوری جمع میشوند تا مسابقه خودروها را در تپه تماشا کنند.
و همانطور که میتوانید تصور کنید، وقتی صدها هزار نفر در یک زمین حضور دارند، اتصال میتواند بسیار چالشبرانگیز باشد.
بلوتوث هم همینطور.
مثلاً این خودرو اساساً یک قفس فارادی است، بنابراین میتوانید تصور کنید که حتی برای اتصال به کلاه ایمنی راننده مسابقه چه چالشهایی وجود دارد.
و درنهایت، الزامات تأخیر کم.
این راننده با سرعت بیشاز ۲۰۰ کیلومتر در ساعت حرکت میکند، بنابراین بسیار مهم است که پاسخهایی که از عامل کمکراننده دریافت میکند، واقعاً سریع و فوری باشند.
و اساساً، ما واقعاً به این موضوع علاقهمندیم زیرا معتقدیم که عاملها در همهجا حضور خواهند داشت.
ما از همین حالا داریم آن را میبینیم.
آنها دیگر فقط در رایانههای ما نیستند.
آنها در تلفنها، ساعتها، عینکها، خانههای هوشمند، و حتی اکنون در خودروهای ما هستند.
و بنابراین، اساساً، ما واقعاً میخواستیم ببینیم در چنین سناریوی سختی چه چیزی میتوانیم بهدست آوریم.
و وقتی داشتیم درباره نحوه ساختن این دستگاه طوفان فکری میکردیم، آیا یک ریزرایانه با یک شتابدهنده کوچک در آن میساختیم تا یک مدل در آنجا داشته باشیم؟
ما به این درک ناگهانی رسیدیم که همه مواد لازم برای این کار ازقبل وجود داشت و آن Android بود.
Android میزبان ایدهآلی برای این کار است چون ADK را دارید که «کیت توسعهدهنده عامل» ما است.
این کتابخانه بسیار خوبی است که به شما امکان میدهد عاملها را مستقیماً در برنامه خود بسازید.
میلیاردها کاربر وجود دارد، بنابراین، و، میدانید، ابعاد مختلفی که میتوانیم این را بهراحتی روی آنها اجرا کنیم، بنابراین آزمایش این و توزیع خود کد واقعاً آسان است.
«ابزارهای توسعهدهندگان» که به شما امکان میدهد اشکالزدایی کنید و چیزهای مختلف را امتحان کنید و ببینید مشکل از کجاست.
هوش مصنوعی دروندستگاهی، تلفنهای Google Pixel اکنون با TPU درست در خود تلفن عرضه میشوند، که برای مدل دروندستگاهی که درست در تلفن قرار دارد بهینهسازی شده است، و دسترسی به یک مدل واقعاً قدرتمند را بااستفاده از میاناهای برنامهسازی کاربردی مانند ML Kit بسیار آسان میکند.
سپس، چیزهایی مانند نوشتار به گفتار و تشخیص گفتار را نیز داریم، میاناهای برنامهسازی کاربردی کاملاً آفلاین که به شما امکان میدهند تجربههای مکالمهای واقعاً قدرتمندی داشته باشید.
و سپس، در نهایت، بدیهی است، اتصالپذیری.
تلفنها برای اتصال ساخته شدهاند، چه ازطریق شبکههای تلفن همراه، Wi-Fi، یا وسایل دیگر.
بنابراین، یکی از چالشها این است که عوامل در لبه نمیتوانند همه کارها را انجام دهند، پس چگونه میتوانند با عوامل، احتمالاً در Cloud، کار کنند؟
و اگر راهحل ترکیبی بود چه؟
چه میشود اگر عاملی که در تلفن زندگی میکند بتواند مستقیماً با عاملی در Cloud صحبت کند تا بتواند اقدامات پیچیدهتری انجام دهد؟
مثلاً میتوانید تصور کنید که راننده میخواهد بداند در چه جایگاهی از مسابقه قرار دارد.
خب، خود خودرو نمیداند در چه جایگاهی از مسابقه قرار دارد، اما شاید عاملی در Cloud بداند.
و ما پروتکلی بهنام «عامل به عامل» داریم، به این معنی که میتوانید عاملهایی را در لبه و در Cloud ایجاد کنید و آنها را مستقیماً با یکدیگر در ارتباط قرار دهید تا اقدامات پیچیدهتری انجام دهند.
خب، چطور آن را ساختیم؟
بنابراین، من قصد دارم شما را با نوعی از اجزای این سیستم آشنا کنم.
شروع از مهار.
اکنون، مهار اینجا اساساً یک برنامه Android است که Agent Developer Kit برای Android را اجرا میکند.
بخش دوم یک مدل است.
برای تقویت آن به یک مدل نیاز دارید و ما از Gemini Nano ازطریق ML Kit استفاده میکردیم، یک مدل دروندستگاهی واقعاً قدرتمند که درست در دسترس شما است.
سپس، دادهها.
اولی قرار است کمی درباره این موضوع صحبت کند، اما شما دادههایی را دارید که از خودرو میآیند، و همچنین، احتمالاً، تشخیص گفتار از راننده.
و درنهایت، کنشهایی را دارید که نماینده میتواند انجام دهد.
این میتواند نوشتار به گفتار باشد تا بتواند با راننده صحبت کند و سؤالات تعقیبی بپرسد یا اطلاعات لازم را ارائه دهد، یا همانطور که قبلاً ذکر شد، ارتباط عامل به عامل با عاملی در فضای ابری برای انجام برخی از اقدامات پیچیدهتر باشد.
اکنون میخواهم از اولی دعوت کنم تا به روی صحنه بیاید و کمی درباره اینکه چگونه این کار را با فرمول E انجام دادیم صحبت کند.
متشکرم، الستر.
خب، مواد لازم را داریم، حالا نوبت بخش سخت است: چطور یک عامل هوش مصنوعی را در خودرو فرمول E ادغام کنیم؟
بنابراین، از اینجا در VCU یا واحد کنترل خودرو شروع میشود.
اکنون، هر حسگر و هر قطعه در خودرو ازطریق چیزی بهنام CAN bus به آن گزارش میدهد.
و خودرو هزاران نقطه دورسنجی در ثانیه تولید میکند، چیزهایی مثل سرعت، شتاب، دریچه گاز، ترمز، و غیره.
بنابراین، برای اتصال-- بنابراین، برای خواندن این دورسنجی، تصمیم گرفتیم یک رزبری پای را مستقیماً ازطریق این اتصال CAN به VCU خودرو متصل کنیم.
اکنون، رزبری پای چند کار مختلف انجام میدهد.
ابتدا، سیگنالهای خام را رمزگشایی میکند، آنها را تبدیل میکند، و آنها را به حدود ۱۰ هرتز کاهش میدهد، که اطلاعات زیادی برای کمکراننده است.
سپس Raspberry Pi این دادههای پالایششده را ازطریق MQTT در Pixel 10 Pro که در کابین خودرو قرار دارد منتشر میکند.
و این یکی از ورودیهایی است که برنامه میزبان برنامه عامل ما میتواند بپذیرد.
دومی تشخیص گفتار Android است.
بنابراین، وقتی راننده صحبت میکند، برنامه ورودی را به نوشتار تبدیل میکند و Gemini Nano میتواند درباره هر دو این ورودیها استدلال کند.
اکنون، نماینده میتواند دو تصمیم بگیرد: اول، میتواند از موتور نوشتار به گفتار Android برای صحبت کردن با راننده استفاده کند.
و دوم اینکه، همانطور که الستر قبلاً اشاره کرد، میتواند ازطریق پروتکل A2A با عامل ابری صحبت کند.
اکنون، در این زمینه، جریان عامل بسیار ساده است: کلمه کلیدی را بگویید، در این مورد «سلام، Gemma»، سؤالی بپرسید و پاسخ دریافت کنید.
نماینده حدود ۵ ثانیه پساز آن به گوش دادن ادامه میدهد تا بتوانید بدون نیاز به شروع مجدد، سؤال پیگیری بپرسید، درست مثل صحبت کردن با یک مهندس مسابقه واقعی.
این برنامه همچنین یک عامل چندنوبتی است، به این معنی که میتواند به سابقه مکالمه دسترسی داشته باشد تا بتواند مکالمهایتر باشد.
بنابراین، ممکن است انتظار داشته باشید که کد این کار کمی پیچیده به نظر برسد، درست است؟
خب، معلوم شد که درواقع خیلی ساده است.
چند خط اول onDeviceModel را بااستفاده از ML Kit فراخوانی میکند و آن را بهعنوان 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 تعریف میکنیم.
نامی برای آن انتخاب کنید و دو نوع دستورالعمل به آن بدهید: اولی دستورالعمل ثابت است که شخصیت و هویت آن را مشخص میکند.
و این میتواند شامل مواردی مانند نحوه صحبت کردن با راننده و برخی اطلاعات درباره پیست مسابقه باشد.
دومی دستورالعمل پویا است.
اکنون، این اطلاعات در هر پُرسمان با جدیدترین خلاصه دورسنجی تولید میشود، بنابراین نماینده همیشه میداند راننده در هر لحظه چه کاری انجام میدهد.
همانطور که قبلاً ذکر شد، سابقه مکالمه فعلی را نیز شامل میشود.
علاوهبراین، ما برخی ابزارها را نیز تعریف میکنیم، برای مثال، به آن توانایی پاسخ دادن به دادههای جلسه قبلی، توانایی پاسخ دادن به عامل ابری، و همچنین توانایی پاسخ دادن به راننده بااستفاده از نوشتار به گفتار را میدهیم.
اکنون بیایید یک نمایش سریع از عامل درحال کار روی شبیهسازهای رانندگی در دفتر فرمول E ببینیم.
سلام Gemma، فرماندهی من چقدر تهاجمی است؟
آرام و سنجیده.
قفل اوج ۴۸ درجه بود و شما فرمان را بهطور میانگین ۱۱ درجه در ثانیه میچرخاندید.
سلام Gemma، اوج شتاب گرانشی من چقدر است؟
اوج شتاب گرانشی ۲٫۲ G در پیچها بود.
سلام Gemma، دویدن من چطور بود؟
عالی بود، Dan.
حداکثر سرعت ۳۰۶ کیلومتر در ساعت، با میانگین ۱۸۶ کیلومتر در ساعت در ۳۵ ثانیه.
۵۸٪ از زمان را با حداکثر سرعت رانندگی کردید و به اوج ۲٫۲ G رسیدید.
پس همین است.
این Gemini Nano در تلفن است که با راننده صحبت میکند و بهطور همزمان به سؤالات او پاسخ میدهد.
شبیهساز رانندگی یک چیز است، خودرو فرمول ای چیز کاملاً متفاوتی است.
پس چطور همه اینها را کنار هم قرار دادیم؟
ابتدا باید به Spark Racing Technology در پاریس، جایی که خودروهای ما ساخته میشوند، سفر میکردیم.
این من هستم در سمت چپ که دارم رزبری پای را به VCU واقعی خودرو فرمول ای سیمکشی میکنم.
هر چیزی که تاکنون ساختهایم روی دادههای شبیهسازیشده اجرا شده و از یک جلسه آزمایشی بازپخش شده است، بنابراین واقعاً نمیدانستیم که آیا با چیز واقعی کار میکند یا نه.
بنابراین آن را به برق وصل کردیم، روشن کردیم، منتظر ماندیم، کمی بیشتر منتظر ماندیم، و درنهایت دورسنجی در دستگاه شروع شد و ثابت کرد که دادهها همانطور که انتظار داشتیم در سیستم حرکت میکنند.
در سمت راست، میتوانید سیستم تکمیلشده را ببینید و میتوانید ببینید که تلفن درواقع در کابین خلبان، درست در کنار جایی که راننده مینشیند، پیادهسازی شده است.
بنابراین، همه ما برای گودوود آماده بودیم.
پس در آن روز واقعاً چه اتفاقی افتاد؟
خب، آن چهار چالشی را که الستر قبلاً دربارهشان صحبت کرد بهخاطر دارید؟
گودوود واقعاً دوتا از آنها را آزمایش کرد.
اکنون، اولین مورد گرما بود.
اکنون، در بریتانیا، ما معمولاً فقط برای هر آب و هوایی به جز آفتاب برنامهریزی میکنیم.
بنابراین، طبیعتاً، آنچه بهدست آوردیم یکی از گرمترین هفتههای ثبتشده بود، درست در میان یک موج گرما.
بهترین زمان برای قرار دادن رایانه در خودرو فرمول ای.
اما نکته جالب اینجاست.
تلفن درواقع سالم بود.
Android واقعاً هیچ آسیبی ندید.
معلوم شد که «رزبری پای» بیشترین مشکل را داشت.
و چون نمیتوانستیم آن را مستقیماً به خودرو وصل کنیم، مجبور شدیم از چیزی بهنام UPS استفاده کنیم که اگر نمیدانید چیست، اساساً شبیه به تعدادی باتری است که به زیر Pi چسبانده شده است.
اما خوشبختانه توانستیم با شارژ کردن گاهبهگاه آن درطول روز این مشکل را برطرف کنیم و بدون این کار، خودرو احتمالاً نمیتوانست بدون عامل هوش مصنوعی از آن تپه بالا برود.
بعدی بلوتوث بود.
در آن زمان، ما هرگز با کلاه ایمنی راننده که ازطریق بلوتوث به برنامه متصل میشود آزمایش نکرده بودیم.
و این کار کمی چالشبرانگیز بود.
بنابراین، برای آزمایش این موضوع، روی چمن نشستیم و بهنظر میرسد که واقعاً اوقات خوبی را سپری میکنیم، درست است؟
رایانههای کیفیمان را بیرون آوردیم و گپ خوبی داشتیم.
خب، در واقعیت، احتمالاً آن دوره یکی از پراسترسترین دورههای حرفه من تا به امروز بود.
ما بهشدت تلاش میکردیم تا آن کد را بهخوبی اجرا کنیم و کلاه ایمنی بلوتوث را قبلاز اینکه راننده بعدازظهر به بالای تپه برود به برنامه متصل کنیم.
اما بهلطف برخی اصلاحات فوری لحظه آخری و ابزارهای عالی اشکالزدایی Android، توانستیم آن را بهموقع برطرف کنیم و خودرو با عامل هوش مصنوعی که عالی کار میکرد از تپه بالا رفت.
اکنون، دوباره به الستر برمیگردم که قرار است کمی بیشتر درباره درسهایی که از این پروژه آموختهایم با ما صحبت کند.
سپاسگزاریم.
متشکرم، اولی.
و بنابراین، از این پروژه چه آموختیم؟
خب، اولی این است که Android واقعاً میزبان فوقالعادهای برای عاملهای شما است.
من شما را بهشدت تشویق میکنم که از تطبیقپذیری Android، میاناهای برنامهسازی کاربردی دردسترس شما، مدلهای دروندستگاهی، و ADK استفاده کنید.
آنها را امتحان کنید چون شگفتزده خواهید شد که از چنین چیز سادهای چه تجربههای قدرتمندی میتوانید بهدست آورید.
جهنم یکپارچهسازی هنوز وجود دارد.
اکثر افراد حاضر در این اتاق احتمالاً در مقطعی از حرفه خود این را تجربه کردهاند.
شما همه زیرمجموعهها را جداگانه میسازید، و سپس وقتی در نهایت به هم وصل میکنید، چیزی درست کار نمیکند.
و کلاه ایمنی راننده مسابقه دقیقاً همین بود.
اما خوشبختانه توانستیم آن را در همان روز برطرف کنیم و این واقعاً ثابت میکند که آزمایش کردن هنوز هم بسیار حیاتی است.
و درنهایت، Gemini Nano.
Gemini Nano در اینجا واقعاً قهرمان بود.
این مدل واقعاً مؤثر است و خیلی سریع در دستگاهتان اجرا میشود و میتواند تکالیف واقعاً پیچیدهای را انجام دهد، اما این کار را بلافاصله انجام نمیدهد.
واقعاً پشت این ایده فکر شده است.
باید مهندسی پیامواره انجام دهید.
باید آن را امتحان کنید.
باید به نحوه ارائه دستورالعمل پویا درمقابل دستورالعمل ایستا فکر کنید.
باید به ابزارهایی که میخواهید به آن بدهید و اینکه چگونه میتوانید به بهترین شکل به آن دستور دهید تا این کار را انجام دهد فکر کنید.
اما با آزمایش و ارزیابی درست، میتوانید از مدلی مثل 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 */
)
)