前言

2026年10月13日，Google 發表了全新的 AI 模型「Gemini 4 Argon」。

說到 Gemini，大家通常會想到文字聊天、程式碼生成，以及多模態的圖片／影片理解等各式各樣的用途。

我在查找 Gemini 4 Argon 的相關資訊時，發現其應用領域之一竟然介紹了**Robotics（機器人學）**。

Google 官方部落格「Gemini 4 Argon for Robotics」中，公開了多個示範，例如四足機器人踩下垃圾桶踏板把空罐丟進去，或是機械手臂一邊確認攝影機畫面一邊操作物體。

這不只是單純辨識影像並加以說明，而是理解周圍的物理狀況，並進一步連結到機器人的具體動作。

我不禁想著，Gemini 竟然連這種事情都能做到，於是決定實際試試看。

這次我將 Gemini 4 Argon 與物理模擬器 MuJoCo 結合，挑戰讓機器手臂完成 Pick & Place（抓取物體並搬運到指定位置的操作）。

Gemini 4 Argon for Robotics 是什麼？

Google 的官方部落格介紹了 Gemini 4 Argon 在機器人領域的多種應用。

領域主要應用範例Robot Control理解周遭狀況並規劃機器人行動Real2Sim從現實世界的圖片或影片建立物理模擬環境Physical Understanding理解物體的位置關係、接觸與動作狀態等Research & Self-improvement利用模擬來驗證並改善機器人的動作其中我特別關注的是 Robot Control。

官方部落格中展示了 Argon 參照機器人的攝影機影像與感測器資訊，進而高層次判斷下一步應採取的操作。

一般來說，要驅動機器人需要「辨識操作對象」「規劃移動路徑」「控制各關節馬達」等多個流程。將 Gemini 的視覺理解與推論能力嵌入這段辨識／判斷流程後，就能把自然語言指令轉換成機器人的自主動作。

這次我便基於這個概念，實作了一個簡單的 Pick & Place 任務。

這次製作的內容

我在工作台上放置了紅、藍、黃三個方塊，讓 Gemini 4 Argon 判斷「該操作哪個方塊，以及要移動到哪裡」。接著根據這個判斷結果，驅動機器手臂抓起目標方塊，搬運到指定的位置。

實際運作的影片如下。

這次使用的技術堆疊如下。

技術職責Gemini 4 Argon理解攝影機影像並判斷操作對象Google CloudGemini API 的執行環境MuJoCo機器人的物理模擬Franka Panda用來操作方塊的機器手臂Python機器手臂的動作控制（軌跡生成與 IK）### MuJoCo 是什麼？

MuJoCo（Multi-Joint dynamics with Contact）是 Google DeepMind 開發並公開的物理模擬引擎。

它能高精度計算機器人的關節運動，以及物體受到的重力、摩擦、碰撞與接觸等物理現象。

例如，當機器手臂抓取方塊時，不只是單純改寫方塊座標，而是可以模擬「夾爪指尖接觸方塊，因摩擦力而夾住並抬起」這整段物理行為。

也就是說，不需要準備實體機器，也能驗證符合物理法則的真實機器人操作，這是它最大的優勢。

這次我便善用 MuJoCo，驗證 Gemini 選出的物體是否能被虛擬機器手臂正確抓起並搬運。

Franka Panda 是什麼？

Franka Panda 是一款在機器人研究與工業用途上廣泛使用的機器手臂。

它最大的特色是具備 7 自由度（7-DoF）。簡單來說，就是手臂上有 7 個可動關節。就像人類會協調肩膀、手肘與手腕來移動手臂一樣，機器人也會連動這 7 個關節，靈活調整末端執行器（end effector）的位置與方向。末端還裝有兩指夾爪，可以夾住物體。

這次我使用的是 MuJoCo Menagerie 中公開的 Franka Panda 模型（模擬模型）。

系統架構

這次設計的最大重點，不是讓 Gemini 4 Argon 負責整個機器人控制，而是將高層認知判斷與低層動作控制分工。

Gemini 負責的是「要操作什麼、搬到哪裡」這種大方向、高層級的判斷（任務規劃）。

另一方面，為了到達目標物體而該如何旋轉各個關節、如何計算具體的動作軌跡，則由 Python 控制器端（例如逆運動學）來處理。

透過清楚分離責任範圍，就能把 Gemini 的多模態推論能力，與既有成熟的機器人控制技術自然整合在一起。

實作詳細內容

整體實作分成多個 Python 檔案，這裡會以 Argon 與機器人控制的串接部分為主來說明。

1. 從 MuJoCo 取得攝影機畫面

首先，從 MuJoCo 裡的虛擬攝影機取得工作環境影像。這次準備了兩個視角。

• Top-down：從正上方俯瞰工作台的影像
• Overview：從斜上方拍攝機器手臂與工作台的整體影像

run_multi.py 的對應程式如下。

first_topdown = output / "00_topdown.png"
first_overview = output / "00_overview.png"

lab.render_png(first_topdown, "topdown")
lab.render_png(first_overview, "overview")

decision, raw = chosen_policy.decide(
    args.task_id,
    instruction,
    first_topdown,
    first_overview
)

我們將這兩張攝影機影像與自然語言指令一起傳給 Gemini。

這裡最重要的是，完全沒有把「正確方塊的三維座標」或「顏色排列順序」這類中繼資訊提供給 Gemini。操作對象的辨識，全部交由攝影機影像的視覺理解來完成。

2. Gemini 4 Argon 的提示詞設計

這次實作中最費工夫的，就是提示詞設計。

不只是單純下達「請移動方塊」，而是嚴格定義影像的參照方式、需要判斷的項目，以及輸出格式的限制。

以下是實際使用的英文提示詞，翻成日文再轉為此處的中文說明用版本（實驗時是送出英文版給 API）。

# 實際英文提示詞的中文翻譯版，僅供說明用

prompt_ja = f"""
你是一個在 MuJoCo 模擬器上操作 Franka Panda 的、
基於視覺資訊的高層動作規劃 AI。

【使用者指示】
{instruction}

【環境】
請查看 MuJoCo 的兩張攝影機影像。

影像1：從正上方俯瞰工作台的影像
影像2：從斜上方拍攝工作台整體的影像

工作台上有紅、藍、黃三個立方體。

在立方體初始位置的更遠處，
有兩個綠色或青綠色的圓形放置區。

左右的判斷，
請以影像1畫面中的左右為基準。

【你的角色】
請根據使用者指示與攝影機影像，
判斷以下兩件事：

1. 應該操作哪個立方體
2. 應該移動到哪一個放置區

在選定立方體與放置區之後，
機器人控制器會使用模擬器中的座標，
實際執行操作。

【限制】
你沒有被提供以下資訊。

- 立方體的精確座標
- 立方體顏色與擺放順序的對應
- 正確的操作對象
- 疊加正解標籤的影像

請從攝影機影像中判斷操作對象。

不要直接控制馬達、關節、座標、程式碼，
或實體硬體。

【輸出格式】
只回傳 JSON。

{{
  "action": "pick_place",
  "target": "red_cube|blue_cube|yellow_cube",
  "destination": "left_zone|right_zone",
  "reason": "請用一句簡短文字說明判斷理由"
}}

如果無法從影像中安全判斷，
請回傳以下 JSON：

{{
  "action": "stop",
  "target": "none",
  "destination": "none",
  "reason": "無法判斷的原因"
}}
"""

這份提示詞的重點設計有以下三點。

1. 明確化空間基準（左右關係）
   為了對應「最左邊的方塊」這類指令，我明確指定要以俯視圖（top-down）而非帶有透視變形的斜視圖畫面左右為基準。
2. 嚴格限制回傳動作
   將動作限制為只有 pick_place 或 stop，而且目標與放置區也只能從已定義清單中選擇。如此一來可以避免 Argon 自行生成低層級的馬達指令，也能安全地銜接控制器。
3. 提供安全停止（stop）的備援
   若無法從視覺資訊中確定判斷，就強制回傳 stop，避免靠猜測執行動作。另一方面，Python 端也會驗證收到的 JSON，若包含未知識別字就丟出例外並停止。

3. Gemini API 的呼叫

接著將提示詞與攝影機影像送到 Gemini 4 Argon。這裡使用的是 Google Gen AI SDK 的 Interactions API。

src/multi_policy.py 的主要處理如下。

from google import genai
import base64

client = genai.Client(
    enterprise=True,
    project=project,
    location="global"
)

def image_part(filename):
    return {
        "type": "image",
        "data": base64.b64encode(
            filename.read_bytes()
        ).decode("ascii"),
        "mime_type": "image/png"
    }

response = client.interactions.create(
    model="gemini-4-argon",
    input=[
        {"type": "text", "text": prompt},
        image_part(first_topdown),
        image_part(first_overview)
    ]
)

raw = response.output_text or ""

※ 上面只節錄了主要部分。實際驗證時傳送的是英文版提示詞。

驗證方式採用 Application Default Credentials（ADC），並透過 interactions.create() 一次送出文字提示與兩張 Base64 編碼的攝影機影像。

4. 從判斷結果轉換成物理動作

Argon 回傳的 JSON 會先在 Python 端驗證，再轉換成 MuJoCo 的控制序列。

if obj.get("action") != "pick_place":
    raise ValueError("Action not allowed")

target = obj.get("target")
destination = obj.get("destination")

if target not in COLORS or destination not in ZONES:
    raise ValueError(
        f"Unrecognized cube/zone: {target}/{destination}"
    )

通過驗證的正常動作，會由 run_multi.py 進一步驅動機械手臂。

lab.select_cube(decision.target)

pick_result = lab.pick()

if pick_result["lifted"]:
    place_result = lab.place(
        ZONES[decision.destination]
    )

在 select_cube() 決定目標方塊後，系統會從模擬環境取得該方塊的三維座標，並使用逆運動學（IK: Inverse Kinematics）計算各關節需要旋轉多少，才能讓末端執行器到達目標位置。

接著透過 pick() 執行接近、夾取與抬升，確認成功後再用 place() 將物體搬運並放置到指定區域。

這正是「Argon 決定『操作什麼、搬到哪裡』，Python 控制器負責執行『怎麼動』」的分工。

實驗：移動最左邊的方塊

我實際下達以下指示進行測試。

「請把從上方影像看起來最左邊的方塊，移動到右側綠色的圓形放置區。」

工作台上從左到右依序擺放著「黃、紅、藍」三個方塊，後方則設有兩個綠色目標區。

因此，正確的動作應該是**「抓起黃色方塊，放到右側區域」**。

在指令文字中並沒有出現「黃色」這個詞，Argon 必須自行從俯視圖理解方塊的排列順序（幾何相對位置）才能答對。

Argon 的推論結果

實際上模型回傳的 JSON 如下。

{
  "action": "pick_place",
  "target": "yellow_cube",
  "destination": "right_zone",
  "reason": "The yellow cube is the leftmost cube in the top-down view, and the instruction asks to move it to the right landing zone."
}

如同指示，target 正確指定為 yellow_cube，destination 也正確指定為 right_zone。從 reason 也可以看出，它正確理解了俯視圖中的左右空間關係。

MuJoCo 上的動作模擬

根據這個推論結果，控制器依照以下步驟執行物理模擬。

1. 將機械手臂移到黃色方塊正上方（接近）
2. 下降夾爪
3. 關閉兩指夾爪夾住方塊
4. 將方塊向上抬起（提升）
   
5. 移動到右側放置區正上方
6. 打開夾爪，讓方塊落下並完成放置
   

在 MuJoCo 中，接觸判定與靜摩擦係數都會被實際計算，因此如果手臂指尖滑掉，方塊就會掉落。這證明系統並不是把座標直接瞬移過去，而是透過物理性的夾持方式穩定搬運。

執行結果

實驗結果整理如下。

評估項目結果正確選擇方塊成功（yellow_cube）正確選擇放置區成功（right_zone）夾爪抓取成功方塊抬升成功成功放置到指定位置最終 XY 誤差3.5mm從模擬器的接觸紀錄也能確認，在抬升過程中，夾爪兩指與方塊側面之間一直保持接觸。

最終在 XY 平面上的放置誤差只有 3.5mm，任務完全成功（※這 3.5mm 的誤差是模擬器中的軌跡追蹤與接觸造成的物理誤差，並不代表 Gemini 的位置推估精度本身）。

文章開頭的影片，是把這次模擬結果（關節軌跡資料）匯入 Blender 後，以較真實的方式重新渲染而成的。

從這次實驗學到的事

透過這次嘗試，我確認了Gemini 4 Argon 高階的視覺理解能力，可以作為機器人自主操作中的「認知／判斷層」實際導入。

傳統的規則式控制，只要事先確定目標的顏色或座標，Pick & Place 本身其實不算困難。然而，像「最左邊的那個」「紅色盒子旁邊的那個」這種相對且模糊的指令，就需要能從影像讀取空間配置與上下文的高階解讀能力。

在這次的架構中，我把這種彈性的判斷交給 Argon，並以結構化 JSON 交給控制器，順利補上了自然語言與物理動作之間的落差。

當然，這個實作並不代表已經完成完整的自主控制機器人。
精準取得三維座標、碰撞檢查、關節軌跡生成、夾爪扭力控制等，仍然是由傳統的 Python 控制器負責。另外，這次只針對單一情境驗證，因此像是物體形狀不一致、光照條件改變等情況下的穩健性，仍是未來的課題。

即便如此，「把 LLM／VLM 放在高層任務規劃器的位置，並與低層控制器採用混合式架構整合」這種設計模式的有效性，這次確實讓我感受很深。

下一步：擴展到閉迴路控制（障礙物迴避與重新規劃）

官方部落格中所暗示的機器人應用，還有更進階的方法。

我接下來特別想挑戰的是，一邊用攝影機回饋機器人的動作結果，一邊決定下一步行動的**「閉迴路控制（Closed-loop Control）」**。

例如，運輸路徑上突然出現障礙物時的迴避路線規劃，或是在抓取失敗、方塊掉落時，立刻重新拍攝影像、重新理解現況，並嘗試重試的流程。

若能透過「觀測、推論、行動、評估」的循環，就有機會把系統進化成能靈活適應動態環境的機器人。

總結

這次我嘗試了使用 Google Gemini 4 Argon 的機器人操作模擬。
我驗證了將 Gemini 4 Argon 與物理模擬器 MuJoCo 串接後，讓機器手臂完成 Pick & Place 的可行性。

系統能從自然語言中帶有曖昧性的指令與多視角攝影機影像中，精準辨識目標物體，
並轉換成物理模擬中的機器人動作。

像 Gemini 這樣的生成式 AI，已經不只是文字聊天或資訊搜尋工具，
而是能作為「理解物理世界，並引導真實世界行動的代理」，在 Physical AI 領域發揮作用。

這次因為能在 Windows PC 上輕鬆嘗試，希望大家也可以親自玩玩看。

參考資料

• Gemini 4 Argon for Robotics — Google Developers Blog
• Gemini 4 Argon — Google Cloud 開發者指南
• MuJoCo — Google DeepMind
• MuJoCo Menagerie — GitHub

原文出處：https://qiita.com/kentaro_kawamura/items/118144a5e0c707de12dd