我很高興能再見到您
這是繼上一篇文章之後的第一篇。我是來自日產的Qiita，Nikita的女兒1。上次我介紹了E2E自動駕駛的細節。我認為E2E自動駕駛是汽車與人工智慧（Car x AI）的典範，所以請想像一下在不久的將來，你駕駛著這輛E2E自動駕駛汽車的場景。一開始，你可能會想：
「哇！雖然駕駛座上沒有人，但它卻在移動！”
“雖然沒有人握住手柄，但它仍然在移動！”
你可能會驚嘆，但騎車大約20分鐘後會發生什麼事？不難想像，大多數人都會開始使用智慧型手機。正因如此，我們才開始思考UI/UX，力求讓駕駛E2E自動駕駛汽車的時光更加愉悅。今天，我們想介紹其中一款－AI無線電模擬器「YAGURA R（暫定名：請像怪物一樣稱之為「Yagura」）」。
AI無線電模擬器“YAGURA・R”
事實上，「YAGURA R」已經在2025年7月2日至4日在東京國際展覽中心舉辦的地方政府和公共週上首次公開展出（儘管是作為B2B展覽），我們的一些讀者可能已經去過那裡了。
（僅供參考）
自治體・公共Week
https://www.publicweek.jp/ja-jp.html
莫普拉斯
*日產汽車與三菱商事的合資車型「YAGURA R」在該展位首次亮相。
這款「YAGURA R」有什麼功能？首先，它提供在本地移動旅行服務中播放的廣播節目。該廣播每次都會根據移動旅行服務的路線客製化不同的節目。這得歸功於生成式人工智慧。我將在另一篇文章中介紹廣播節目的生成方式。
如果一輛配備了這種生成廣播的移動出行服務車在你的城鎮行駛，會播放什麼樣的節目呢？ 「YAGURA・R」可以讓你模擬這種體驗。透過指定日本（或世界）的任意地區，系統就會產生一條連接旅遊景點及其相關廣播的路線。然而，「YAGURA・R」不僅讓你收聽廣播，它還提供三種相互關聯的視圖：移動出行服務車上的街景、基於衛星圖像的鳥瞰視圖以及在地圖上移動的移動出行車。而這輛移動的移動出行車就是微型汽車，或者說是「toio」。
「YAGURA R」的魅力在於，你可以將自己的城鎮想像成一輛移動服務車，一邊聽著廣播，一邊看著微型汽車四處行駛，讓你感受到移動服務真的開始了。
照片為地方政府及公眾週活動現場，解說員皆為日產汽車移動出行及人工智慧研究中心的成員。在地方政府及公眾週活動中，許多參觀者體驗了這項活動。
“你能模擬任何地點，真是太神奇了！太有趣了！”
我想立即採用這個系統！
它大獲成功。而且，「YAGURA R」實際上只花了大約一個月的時間就完成了製作，堪稱是充分利用了「振動編碼」（Vibecoding）——一種利用人工智慧（AI）編寫程式的技術——的傑作。關於「振動編碼」我們以後可能會再討論，但今天我們想介紹的是「YAGURA R」的硬體系統。
「YAGURA R」是一款可在任何區域選擇任意POI（興趣點）並產生移動服務路線和GPS資料的系統。結合GPS資料，微型汽車會在投影機上顯示的地圖上行駛，同時AI無線電會播報該POI的資訊。該系統大致分為三個部分。
-
UI 部分可讓您選擇您喜歡的區域和 POI
-
沿著連接選定興趣點的路線行駛的微型汽車俱樂部
-
沿途進行廣播的人工智慧部分
這次我想解釋一下第1點和第2點。
UI 部分可讓您選擇您喜歡的區域和 POI
這次是示範系統，所以我們負責基本操作。你可能會覺得UI的易用性是次要的，但事實並非如此。尤其是像這次這樣每天操作數十次的情況下，如果UI設計時沒有考慮到易用性，即使是演示系統，也有可能在用戶面前出現錯誤，導致我們想要透過演示系統傳達的訊息無法完全傳達。因此，這次我們的目標是打造一個「無論嘗試多少次，任何人都可以輕鬆操作」的UI。
最初，我設想了一種透過輸入「地區 + 類型」來選擇 POI 的方法，類似於在 Google 上搜尋的方式。然而，類型選擇起來比較棘手，呼叫 Google Maps API 函數時顯示出來的 POI 往往與你預想的 POI 不同。例如，如果你選擇“餐廳”作為類型，你肯定希望看到美味的拉麵店和供應當地特色菜的日式餐廳，對吧？然而，酒店和旅館內的小餐館也會顯示出來，這讓你很難選擇真正想去的 POI。這是因為 Google Maps 上預先註冊的 POI 類別過於寬泛，因此我透過在 Python 程式碼中加入基於規則的處理來解決這個問題，如果 POI 名稱包含“飯店”、“旅館”或“旅館”，則不會在搜尋結果中顯示該 POI。
此外，在選擇“旅遊景點”作為類型時，我最初在谷歌地圖的POI類別中加入了“公園”，以便顯示像橫濱山下公園這樣的著名旅遊公園。然而，這也導致住宅小區裡的小公園也出現了，所以我從類別中移除了「公園」（不過，如果你想建立一條秘密約會路線，這或許是必要的♡）。
另外，最讓我頭痛的是「歷史」題材。一開始我以為「歷史」題材肯定會受到一般大眾和愛好者的追捧！我以為會出現當地的寺廟和城堡，所以…
“讓我們乘坐汽車巡遊鎌倉的歷史吧！這是一次能讓您感受到源賴朝氣息的旅程。”
“探索京都的歷史真是太令人興奮了！你甚至可能會聽到小野小町問：‘花是什麼顏色的？’”
我原本希望 AI 電台的播放體驗流暢，但當我在谷歌地圖上使用“historical_landmark”興趣點類別時，它竟然顯示了銀行和工廠。雖然確實有歷史悠久的銀行和工廠，但來鎌倉的顧客聽到「歷史」這個詞時，不太可能會想去工廠或銀行看看。我考慮過建立一個要移除的工廠和銀行列表，並在 Python 中加入基於規則的程式碼，就像上面提到的那樣。但由於這是一個隨機區域，我決定建立一個龐大的清單來移除不太實際。所以，我無奈地從類別中刪除了“歷史”，並用“旅遊景點”和“自然”取而代之。圖片展示了部分 UI，您可以看到效果。
最後，在操作UI方面，我們盡可能地減少了文字輸入，並建立了一個只需輕點幾下即可完成操作的UI框架，從而減輕了操作負擔和出錯的可能性（實際上，當您選擇北海道時，下一頁會顯示64個郡縣的名稱，但是由於滾動困難而無法找到它們，因此我們將其設置為文字輸入區域）。
據開發人員介紹，「為了確保像這次這樣的操作性和質量，需要進行大量的測試，並反覆進行發現和修復錯誤的循環。」正因如此，在三天的製作過程中，操作介面幾乎沒有出現任何錯誤。即使可以使用諸如Vibe編碼之類的方法輕鬆編寫程序，但最終提升產品品質的仍然是專業的人眼。
沿著連接選定興趣點的路線行駛的微型汽車俱樂部
我們最近的研究一直在探索，如果世界上沒有顯示器，UI 會是什麼樣子。挑戰在於，我們能否透過刻意施加「沒有顯示器」的限制，創造出一種全新的 UI。簡而言之，我們的目標是使用非顯示器的物體，打造一個易於理解且易於使用者使用的 UI。 「YAGURA R」也配備了一個用於顯示街景的顯示器，但即使沒有顯示器，一輛移動出行服務微型車也會根據投影機投影的地圖和路線行駛，讓您能夠清晰地知道自己正在沿著正確的路線行駛。這輛微型車是上一篇文章中提到的 E2E 自動駕駛實驗車的迷你版！它看起來真可愛！
你知道這輛迷你汽車是怎麼運作的嗎？試駕過的人說：
“什麼？！它是靠下面的磁鐵驅動的，對吧？”
“這麼小的東西（大約4立方厘米）是如何工作的？！”
我們常常收到這樣的問題，沒錯！如果你熟悉它，從照片中就能看出，我們使用的是索尼互動娛樂的立方體機器人玩具——toio。
（僅供參考）
小型立方體機器人玩具，toio
這輛微型汽車需要體積小巧，並且能夠進行無線通信，因為它可以沿著連接任何區域內任何興趣點的路線行駛。就在所有開發人員都在思考他們能想出什麼點子時，一位開發人員突然想到：「也許我們可以用我送給姪女的那輛程式設計學習微型汽車！」 於是，toio 應運而生。
toio 的尺寸約為 3x3x2.5 厘米，底部的光學感測器讀取印在 toio 專用墊子上的微點（肉眼幾乎看不見），從而確定 x 和 y 座標以及角度。所有元件，包括兩個馬達、齒輪、一個電池、一個光學感測器和一個通訊晶片，都塞進了這個小巧的體積裡！是不是很棒？現在，我們準備好了所有工具，但正如你所想像的，真正的行動才剛開始：使用 toio 建立一個系統。
首先，我們來談談資料通訊。該系統將 GPS 資料與 toio 墊上的座標進行匹配，並根據這些座標移動 toio。僅憑這一點，就足以透過 PC 和 toio 之間的藍牙 (BLE) 通訊進行操作。但是，該系統會根據操作介面中選擇的 POI 產生 GPS 資料，然後使用該 GPS 資料產生並播放街景和 AI 廣播。這需要在多台 PC 和裝置之間實現無延遲的資料通訊。因此，我們使用了輕量級且高效的 MQTT 協定。 MQTT 不僅能夠實現多台 PC 和裝置之間的無延遲資料通信，還能讓系統隨時隨地在線上運作。此通訊系統還可用於協調移動出行服務車輛和微型汽車。
接下來，我們將介紹一些確保toio墊子順暢執行的技巧。可供toio移動的toio墊子有A4和A3兩種尺寸。最多可以連接12個A3尺寸的toio墊子（4x3），從而建立一個絕對座標約為1.2m x 1.2m的墊子。這次，我們連接了兩個A3尺寸的toio墊子（x和y座標：x=34, y=35至x=644, y=466），以匹配「YAGURA R」的尺寸。然而，在實際執行toio時，其IdInformation有時會顯示“非數字”，導致其失去位置並停止。經過進一步研究，我們發現光學感測器由於墊子之間的間隙等原因無法正確讀取資料。因此，我們加入了一個程序，當IdInformation顯示“非數字”時，每0.1秒移動一次toio馬達以獲取其座標。
if cube1.air: # ID information of Toio is NaN
await cube1.api.motor.motor_control(10, 10)
await asyncio.sleep(0.1)
await cube1.api.motor.motor_control(0, 0)另外，墊子有時會錯誤地讀取我設定的座標以外的座標（例如，x=1600，y=600）。發生這種情況時，toio 會嘗試加速到這些座標，所以我加入了一個程式來阻止它移動。
if X < 1500 and X > 0 and Y < 500 and Y > 0 and cube1.reached_to_target == False:
await cube1.cubeMoveTo(X, Y, 20)最後，我們將介紹一個巧妙的方案，讓 toio 與 GPS 資料協同工作。給 toio 的指令基本上是“以 ◇◇ 的速度前往 x 坐標 XX，y 坐標 △△”，但在這個系統中，AI 無線電會在每個 POI 處進行通話，因此它需要在 POI 附近停留更長時間，如果無法到達，則立即衝算一個 POI （如果我們以高速行駛速度，但由於速度行駛，因此無法到達，則立即衝算一個 POI（如果您是高速行駛速度，但由於速度行駛），這意味著由於我們以高速行駛速度，這意味著我們以高速行駛速度。我們透過根據需要自動調整發送給 toio 的目的地座標之間的距離來解決這個問題。
系統會隨時計算從發送給toio的目的地座標到光學感測器從墊子讀取的座標之間的距離。如果距離在5毫米或以上，機器人就會移動到目的地座標；如果距離在5毫米或以下，機器人就會停留在目前位置。這意味著，在目的地座標之間距離較近的區域，機器人會停留更長時間，讓您可以悠閒地聆聽AI無線電的對話。我們最初嘗試將這個5毫米距離調整到10毫米，但發現停留時間不夠長；而嘗試1毫米時，又會幹擾相鄰的目的地座標，因此我們反覆試驗，最終調整了距離。此外，當下一個目的地座標距離太遠時，我們將toio的速度加倍；同時，由於突然增加速度會導致toio滾動，因此我們調整了加速度。這次經驗讓我們深刻體會到，即使是市面上常見的穩定移動物體，也需要設計出各種使用方法。
最後，我們向開發者徵求了意見。他們給了許多鼓勵性的意見，讓我們對未來的版本更新充滿期待。例如，「這次時間緊迫，我們把toio的左右電機速度設定為相同，讓它只能直線行駛。但實際上，我們希望系統能夠考慮到左右輪胎的速度差異，以便它能夠沿著道路的彎道行駛（計算彎道半徑和左右輪胎的速度差異非常困難）。」「這次它從一個點移動到另一個點時會有點卡頓，但如果我們根據兩個目標點的座標資料進行計算，並增加延遲，它應該能夠更順暢地行駛。
結論
嗯，這次我介紹了AI無線電模擬器“YAGURA・R”，它是UI/UX研究計畫之一。寫下這些，讓我回想起我們遇到的許多巧妙想法和挑戰。此外，我們也正在考慮其他UI/UX，既包括“YAGURA・R”，也包括其他「YAGURA・R」以外的UI/UX，敬請期待！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式