菜单

具身智能：零基础入门睿尔曼机械臂（四）—— 夹爪无响应？官方例程踩坑与排错实战

承接官方夹爪范例，本篇记录末端“能动臂、爪子完全不动”的完整排错链路：逐项核对脚本与示例、实测末端供电、还原官方范例缺的电压初始化，并追到示教器的通讯／波特配置。

一、前言

上一篇我们基于睿尔曼官方夹爪控制例程，拆解了夹爪“抓取-释放”的核心代码逻辑，从参数含义、函数作用到执行流程做了全维度解析，本以为只需按例程部署就能完成实操落地，却在实际安装夹爪并运行代码时遇到了核心问题——机械臂关节运动完全正常，但末端夹爪始终无任何物理动作。

指令一直返回的是超时（错误码-4），夹爪既不闭合也不张开，完全处于“瘫痪”状态。不同于上一篇梳理的“参数错误”“sleep时间不足”等基础问题，本次故障的根源隐藏在官方例程的初始化环节——遗漏了末端端口电压配置和通信协议初始化。本文将完整还原本次排错过程，从“软件复查→硬件测量→通信排查”三个维度定位问题，并给出可落地的解决方案，帮大家避开官方例程的“坑”。

二、问题发现：例程指令成功，夹爪却“纹丝不动”

2.1 实操环境确认

硬件：睿尔曼第三代机械臂（RM_65）+ 配套电动夹爪（已按手册完成末端机械安装，接口无松动）；
软件：复用上一篇的夹爪控制例程，speed（500）、force（200）、IP/端口（192.168.1.18:8080）、time.sleep()时间（2秒）均确认无误；
网络：电脑与机械臂同网段，ping通无丢包，机械臂关节运动（movej）执行正常。

2.2 异常现象

运行例程后终端打印均为“成功”，但核心异常突出：

  • 机械臂按指令完成“初始位→抓取位”的关节运动，终端打印“movej motion succeeded”；
  • 夹爪抓取/释放指令返回-4超时错误码
  • 夹爪全程无任何物理动作，既不闭合也不张开，手动轻掰夹爪无任何阻力（典型的未上电状态）。

我们逐一排除了上一篇总结的基础问题，确定故障并非代码调用错误，而是更深层的初始化缺失。

三、抽丝剥茧：从“软件复查”到“硬件+通信”的排错全过程

面对“指令成功但硬件无动作”的矛盾现象，我们按“软件→硬件→通信”的逻辑逐步溯源，最终定位到官方例程的两处关键遗漏。

3.1 第一步：软件层面——复查例程与SDK文档，无明显错误

首先聚焦“软件逻辑”做全面核查：

  1. 对比官方夹爪例程完整代码，确认set_gripper_pick_on/set_gripper_release函数调用格式、参数范围均符合SDK要求；
  2. 查阅睿尔曼SDK官方文档（rm_robot_interface.py注释+官网技术手册），确认夹爪无需独立建立连接，只需机械臂连接成功即可；
  3. 打印机械臂连接句柄（handle.id≠-1）、API版本（rm_api_version()），均显示正常，无版本兼容问题。

软件层面未发现任何问题，我们判断故障大概率出在“硬件供电/通信”环节。

3.2 第二步：硬件层面——万用表实测，末端端口电压为0

针对“夹爪无上电迹象”（手动可轻易掰动），我们对机械臂末端夹爪连接端口做了硬件测量：

  1. 断电状态下，按手册核对夹爪供电接口与机械臂末端端口的针脚定义，确认接线匹配；
    在这里插入图片描述
  2. 上电后，用万用表测量末端端口的电源输出引脚，发现电压值为0V（正常应为12V/24V，适配夹爪额定供电）。

这一发现直接指向核心线索：夹爪未获得供电，即便指令“成功”，硬件也无执行基础。

3.3 第三步：溯源电压问题——官方例程遗漏电压初始化函数

找到“电压为0”的线索后，我们重新梳理SDK函数列表，发现睿尔曼SDK中提供了rm_set_end_out_voltage（注：函数名以实际SDK为准）等修改末端端口输出电压的函数，但在官方夹爪控制例程的__init__初始化函数中，仅执行了机械臂连接操作，完全未调用该电压配置函数，导致末端端口默认输出0V，夹爪无供电。

我们在初始化函数中补充调用电压配置函数（设置为24V，适配夹爪额定电压），重新运行例程：

  • 夹爪立即出现上电反应：自动闭环→张开至最大行程，手动掰动夹爪有明显阻力（闭环锁定状态）；
  • 但新问题出现：执行set_gripper_pick_on/set_gripper_release指令，夹爪仍不执行抓取/释放动作。

3.4 第四步：通信层面——示教器排查，通信协议未配置

夹爪上电但指令不执行，说明“供电问题解决，但通信异常”。我们进入机械臂示教器，核查夹爪相关配置项：

  1. 找到“末端执行器→通信配置”页面，发现波特率、校验位等参数与夹爪手册要求的115200波特匹配并未启动
  2. 确认核心问题：夹爪与机械臂通信协议未初始化，导致机械臂下发的指令无法被夹爪识别，即便供电正常，夹爪也无法响应指令。

至此，问题根源完全明确：官方夹爪例程仅关注“夹爪指令调用”，却遗漏了“末端端口电压初始化”和“通信协议配置”两个关键前提，前者导致夹爪无供电，后者导致指令无法传递。

四、落地解决方案：分维度解决供电与通信问题

针对排查出的两大核心问题，我们整理了两种可落地的解决方案，适配不同使用场景（快速调试/自动化控制）。

4.1 维度1：末端端口电源输出配置

夹爪的正常工作依赖12V/24V的末端供电，需先完成电压配置，以下是两种方法：

方法1：示教器直接配置（快速调试）

  1. 进入机械臂示教器，找到“扩展→末端控制”页面；（博主这边没有连接机械臂不好截图）
  2. 根据夹爪硬件手册，选择“末端输出电压”为12V或24V（原本为0V）（建议优先匹配夹爪额定电压）；
  3. 保存配置并重启机械臂，再次测量末端端口电压，确认数值与设置一致。
    在这里插入图片描述

方法2：代码中调用电压配置函数（自动化控制）

在机械臂初始化函数（__init__）中补充电压配置逻辑，确保每次连接机械臂时自动配置电压，代码示例如下：

def __init__(self, ip, port, level=3, mode=2, gripper_voltage=24):
    """
    Initialize and connect to the robotic arm (and gripper), add gripper voltage configuration.

    Args:
        ip (str): IP address of the robot arm.
        port (int): Port number.
        level (int, optional): Connection level. Defaults to 3.
        mode (int, optional): Thread mode (0: single, 1: dual, 2: triple). Defaults to 2.
        gripper_voltage (int, optional): Gripper rated voltage (12/24). Defaults to 24.
    """
    self.thread_mode = rm_thread_mode_e(mode)
    self.robot = RoboticArm(self.thread_mode)
    self.handle = self.robot.rm_create_robot_arm(ip, port, level)

    if self.handle.id == -1:
        print("\nFailed to connect to the robot arm\n")
        exit(1)
    else:
        print(f"\nSuccessfully connected to the robot arm: {self.handle.id}\n")
        # 补充：配置末端端口输出电压为夹爪额定电压
        voltage_result = =self.robot.rm_set_tool_voltage(2)
        if voltage_result == 0:
            print(f"\nSet gripper voltage to 12V succeeded\n")
        else:
            print(f"\nSet gripper voltage failed, Error code: {voltage_result}\n")

4.2 维度2：通信协议（波特率等）配置

夹爪与机械臂的通信依赖匹配的波特率、校验位等参数，当前睿尔曼SDK暂未提供通信协议配置的函数，需通过示教器完成配置：

  1. 进入示教器“末端执行器→通信配置”页面；
  2. 查阅夹爪硬件手册，确认要求的通信参数（如波特率115200、数据位8、校验位None、停止位1）；
  3. 将示教器中的参数修改为与夹爪匹配的值，保存并重启机械臂；
  4. 验证：重启后夹爪上电，执行抓取/释放指令，夹爪可正常开合。
    在这里插入图片描述

4.3 解决方案组合建议

  • 快速调试场景：示教器直接配置电压+通信协议，无需修改代码，适合临时测试；
  • 自动化部署场景：代码中调用电压配置函数（确保每次连接自动设压）+ 示教器一次性配置通信协议（配置后无需重复修改），适合批量/重复执行的场景。

五、总结与经验沉淀

本次排错过程，核心解决了睿尔曼官方夹爪例程“初始化环节缺失”的问题，也沉淀了机械臂末端执行器故障排查的通用思路：

5.1 问题根源总结

官方夹爪控制例程仅关注“夹爪指令调用”，却遗漏了两个基础前提：

  1. 供电前提：末端端口需主动配置12V/24V输出电压，否则夹爪无供电，指令无物理执行基础；
  2. 通信前提：夹爪与机械臂的通信协议（波特率等）需匹配，否则指令无法被夹爪识别。

5.2 排错思路

遇到“指令成功但硬件无动作”的故障，可按“软件→硬件→通信”的顺序排查：

  1. 软件层：复查代码调用、参数、SDK文档，排除语法/逻辑错误；
  2. 硬件层：用万用表测量供电电压、检查接线/安装，排除“无电/接触不良”；
  3. 通信层：通过示教器核查协议配置，排除“指令无法传递”。

5.3 实操建议

  1. 不要完全依赖官方例程：工业级设备的例程常简化初始化步骤，需结合硬件手册补充配置；
  2. 硬件测量是关键：万用表等工具能快速定位供电问题，比单纯看日志更高效；
  3. 示教器是核心调试入口：机械臂的底层配置（电压、波特率）多在示教器中，需熟悉示教器操作逻辑。

若后续睿尔曼更新SDK，新增通信协议配置的函数，可将通信配置也整合到代码初始化中，实现“一键连接+配置+控制”的全自动化流程。本次排错也印证了：机械臂控制不仅是“代码调用”，更是“软件+硬件+通信”的协同，唯有兼顾全链路，才能真正落地实操。

阅读原文

具身智能：零基礎入門睿爾曼機械臂（四）—— 夾爪無響應？官方例程踩坑與排錯實戰

接續官方夾爪例程，整理「機械臂會動但夾爪不動」的真實除錯路徑：軟體對照 SDK、電表量末端電壓，補上範例遺漏的輸出初始化，並回溯示教器通訊與 baud 設定問題。

來源：https://blog.csdn.net/2403_87969572/article/details/155957848

抓取時間（ISO本地）：2026-05-18 05:17:19

文章目錄

一、前言

上一篇我們基於睿爾曼官方夾爪控制例程，拆解了夾爪“抓取-釋放”的核心代碼邏輯，從參數含義、函數作用到執行流程做了全維度解析，本以為只需按例程部署就能完成實操落地，卻在實際安裝夾爪並運行代碼時遇到了核心問題——機械臂關節運動完全正常，但末端夾爪始終無任何物理動作。

指令一直返回的是超時（錯誤碼-4），夾爪既不閉合也不張開，完全處於“癱瘓”狀態。不同於上一篇梳理的“參數錯誤”“sleep時間不足”等基礎問題，本次故障的根源隱藏在官方例程的初始化環節——遺漏了末端端口電壓配置和通信協議初始化。本文將完整還原本次排錯過程，從“軟件複查→硬件測量→通信排查”三個維度定位問題，並給出可落地的解決方案，幫大家避開官方例程的“坑”。

二、問題發現：例程指令成功，夾爪卻“紋絲不動”

2.1 實操環境確認

硬件：睿爾曼第三代機械臂（RM_65）+ 配套電動夾爪（已按手冊完成末端機械安裝，接口無鬆動）；
軟件：複用上一篇的夾爪控制例程，speed（500）、force（200）、IP/端口（192.168.1.18:8080）、time.sleep()時間（2秒）均確認無誤；
網絡：電腦與機械臂同網段，ping通無丟包，機械臂關節運動（movej）執行正常。

2.2 異常現象

運行例程後終端打印均為“成功”，但核心異常突出：

  • 機械臂按指令完成“初始位→抓取位”的關節運動，終端打印“movej motion succeeded”；
  • 夾爪抓取/釋放指令返回-4超時錯誤碼
  • 夾爪全程無任何物理動作，既不閉合也不張開，手動輕掰夾爪無任何阻力（典型的未上電狀態）。

我們逐一排除了上一篇總結的基礎問題，確定故障並非代碼調用錯誤，而是更深層的初始化缺失。

三、抽絲剝繭：從“軟件複查”到“硬件+通信”的排錯全過程

面對“指令成功但硬件無動作”的矛盾現象，我們按“軟件→硬件→通信”的邏輯逐步溯源，最終定位到官方例程的兩處關鍵遺漏。

3.1 第一步：軟件層面——複查例程與SDK文檔，無明顯錯誤

首先聚焦“軟件邏輯”做全面核查：

  1. 對比官方夾爪例程完整代碼，確認set_gripper_pick_on/set_gripper_release函數調用格式、參數範圍均符合SDK要求；
  2. 查閱睿爾曼SDK官方文檔（rm_robot_interface.py註釋+官網技術手冊），確認夾爪無需獨立建立連接，只需機械臂連接成功即可；
  3. 打印機械臂連接句柄（handle.id≠-1）、API版本（rm_api_version()），均顯示正常，無版本兼容問題。

軟件層面未發現任何問題，我們判斷故障大概率出在“硬件供電/通信”環節。

3.2 第二步：硬件層面——萬用表實測，末端端口電壓為0

針對“夾爪無上電跡象”（手動可輕易掰動），我們對機械臂末端夾爪連接端口做了硬件測量：

  1. 斷電狀態下，按手冊核對夾爪供電接口與機械臂末端端口的針腳定義，確認接線匹配；
    在這裡插入圖片描述
  2. 上電後，用萬用表測量末端端口的電源輸出引腳，發現電壓值為0V（正常應為12V/24V，適配夾爪額定供電）。

這一發現直接指向核心線索：夾爪未獲得供電，即便指令“成功”，硬件也無執行基礎。

3.3 第三步：溯源電壓問題——官方例程遺漏電壓初始化函數

找到“電壓為0”的線索後，我們重新梳理SDK函數列表，發現睿爾曼SDK中提供了rm_set_end_out_voltage（注：函數名以實際SDK為準）等修改末端端口輸出電壓的函數，但在官方夾爪控制例程的__init__初始化函數中，僅執行了機械臂連接操作，完全未調用該電壓配置函數，導致末端端口默認輸出0V，夾爪無供電。

我們在初始化函數中補充調用電壓配置函數（設置為24V，適配夾爪額定電壓），重新運行例程：

  • 夾爪立即出現上電反應：自動閉環→張開至最大行程，手動掰動夾爪有明顯阻力（閉環鎖定狀態）；
  • 但新問題出現：執行set_gripper_pick_on/set_gripper_release指令，夾爪仍不執行抓取/釋放動作。

3.4 第四步：通信層面——示教器排查，通信協議未配置

夾爪上電但指令不執行，說明“供電問題解決，但通信異常”。我們進入機械臂示教器，核查夾爪相關配置項：

  1. 找到“末端執行器→通信配置”頁面，發現波特率、校驗位等參數與夾爪手冊要求的115200波特匹配並未啟動
  2. 確認核心問題：夾爪與機械臂通信協議未初始化，導致機械臂下發的指令無法被夾爪識別，即便供電正常，夾爪也無法響應指令。

至此，問題根源完全明確：官方夾爪例程僅關注“夾爪指令調用”，卻遺漏了“末端端口電壓初始化”和“通信協議配置”兩個關鍵前提，前者導致夾爪無供電，後者導致指令無法傳遞。

四、落地解決方案：分維度解決供電與通信問題

針對排查出的兩大核心問題，我們整理了兩種可落地的解決方案，適配不同使用場景（快速調試/自動化控制）。

4.1 維度1：末端端口電源輸出配置

夾爪的正常工作依賴12V/24V的末端供電，需先完成電壓配置，以下是兩種方法：

方法1：示教器直接配置（快速調試）

  1. 進入機械臂示教器，找到“擴展→末端控制”頁面；（博主這邊沒有連接機械臂不好截圖）
  2. 根據夾爪硬件手冊，選擇“末端輸出電壓”為12V或24V（原本為0V）（建議優先匹配夾爪額定電壓）；
  3. 保存配置並重啟機械臂，再次測量末端端口電壓，確認數值與設置一致。
    在這裡插入圖片描述

方法2：代碼中調用電壓配置函數（自動化控制）

在機械臂初始化函數（__init__）中補充電壓配置邏輯，確保每次連接機械臂時自動配置電壓，代碼示例如下：

def __init__(self, ip, port, level=3, mode=2, gripper_voltage=24):
    """
    Initialize and connect to the robotic arm (and gripper), add gripper voltage configuration.

    Args:
        ip (str): IP address of the robot arm.
        port (int): Port number.
        level (int, optional): Connection level. Defaults to 3.
        mode (int, optional): Thread mode (0: single, 1: dual, 2: triple). Defaults to 2.
        gripper_voltage (int, optional): Gripper rated voltage (12/24). Defaults to 24.
    """
    self.thread_mode = rm_thread_mode_e(mode)
    self.robot = RoboticArm(self.thread_mode)
    self.handle = self.robot.rm_create_robot_arm(ip, port, level)

    if self.handle.id == -1:
        print("\nFailed to connect to the robot arm\n")
        exit(1)
    else:
        print(f"\nSuccessfully connected to the robot arm: {self.handle.id}\n")
        # 補充：配置末端端口輸出電壓為夾爪額定電壓
        voltage_result = =self.robot.rm_set_tool_voltage(2)
        if voltage_result == 0:
            print(f"\nSet gripper voltage to 12V succeeded\n")
        else:
            print(f"\nSet gripper voltage failed, Error code: {voltage_result}\n")

4.2 維度2：通信協議（波特率等）配置

夾爪與機械臂的通信依賴匹配的波特率、校驗位等參數，當前睿爾曼SDK暫未提供通信協議配置的函數，需通過示教器完成配置：

  1. 進入示教器“末端執行器→通信配置”頁面；
  2. 查閱夾爪硬件手冊，確認要求的通信參數（如波特率115200、數據位8、校驗位None、停止位1）；
  3. 將示教器中的參數修改為與夾爪匹配的值，保存並重啟機械臂；
  4. 驗證：重啟後夾爪上電，執行抓取/釋放指令，夾爪可正常開合。
    在這裡插入圖片描述

4.3 解決方案組合建議

  • 快速調試場景：示教器直接配置電壓+通信協議，無需修改代碼，適合臨時測試；
  • 自動化部署場景：代碼中調用電壓配置函數（確保每次連接自動設壓）+ 示教器一次性配置通信協議（配置後無需重複修改），適合批量/重複執行的場景。

五、總結與經驗沉澱

本次排錯過程，核心解決了睿爾曼官方夾爪例程“初始化環節缺失”的問題，也沉澱了機械臂末端執行器故障排查的通用思路：

5.1 問題根源總結

官方夾爪控制例程僅關注“夾爪指令調用”，卻遺漏了兩個基礎前提：

  1. 供電前提：末端端口需主動配置12V/24V輸出電壓，否則夾爪無供電，指令無物理執行基礎；
  2. 通信前提：夾爪與機械臂的通信協議（波特率等）需匹配，否則指令無法被夾爪識別。

5.2 排錯思路

遇到“指令成功但硬件無動作”的故障，可按“軟件→硬件→通信”的順序排查：

  1. 軟件層：複查代碼調用、參數、SDK文檔，排除語法/邏輯錯誤；
  2. 硬件層：用萬用表測量供電電壓、檢查接線/安裝，排除“無電/接觸不良”；
  3. 通信層：通過示教器核查協議配置，排除“指令無法傳遞”。

5.3 實操建議

  1. 不要完全依賴官方例程：工業級設備的例程常簡化初始化步驟，需結合硬件手冊補充配置；
  2. 硬件測量是關鍵：萬用表等工具能快速定位供電問題，比單純看日誌更高效；
  3. 示教器是核心調試入口：機械臂的底層配置（電壓、波特率）多在示教器中，需熟悉示教器操作邏輯。

若後續睿爾曼更新SDK，新增通信協議配置的函數，可將通信配置也整合到代碼初始化中，實現“一鍵連接+配置+控制”的全自動化流程。本次排錯也印證了：機械臂控制不僅是“代碼調用”，更是“軟件+硬件+通信”的協同，唯有兼顧全鏈路，才能真正落地實操。

Embodied intelligence: Realman arm zero-to-one (4)—gripper dead? demo pitfalls and debug

Field report from Realman tooling: joints move yet the gripper stays idle—checking SDK snippets, metering end-effector rails, patching missing initialization calls, and fixing teach pendant comms baud settings.

Captured at (ISO local): 2026-05-18 05:17:19

I. Foreword

In the last post we walked through Realman’s official gripper demo—pick/release calls, parameters, and flow. We expected plug-and-play after mounting the gripper, but hit a hard blocker: joint motion was fine, yet the gripper never moved physically.

Commands kept returning timeout (error code -4)—no close, no open, total “paralysis.” Unlike simple mistakes (wrong parameters, short sleep), this traced to missing init in the official demo: tool voltage and serial protocol were never set. This article replays the full debug path—software → hardware → comms—and gives fixes so you can skip the same traps.

II. Symptom: “success” in logs, gripper won’t move

2.1 Test setup

Hardware: third-gen RM_65 + electric gripper (mechanically installed per manual, connectors tight);
Software: same gripper demo as before—speed 500, force 200, IP/port 192.168.1.18:8080, time.sleep(2) verified;
Network: same subnet, ping clean, movej works.

2.2 What we saw

Terminal looked partly healthy, but the gripper did nothing:

  • Arm moved home → grasp pose; “movej motion succeeded” printed;
  • Pick/release returned -4 timeout;
  • No jaw motion; fingers moved freely by hand—classic unpowered gripper.

We ruled out the basics from the previous article—this was deeper missing initialization.

III. Debug trail: software → hardware → comms

“Commands OK but hardware silent” → we traced software → hardware → communication and found two gaps in the official demo.

3.1 Step 1: software—demo and SDK look fine

  1. Compared full official gripper script—set_gripper_pick_on / set_gripper_release format and ranges match the SDK;
  2. Read rm_robot_interface.py and the web manual—no separate gripper connection; arm handle is enough;
  3. handle.id ≠ -1, rm_api_version() OK—no version clash.

Software looked clean → suspect power or serial.

3.2 Step 2: hardware—0 V at the tool port

Gripper felt unpowered (easy to move by hand):

  1. Power off, verified pinout vs manual;
    在这里插入图片描述
  2. Power on, multimeter on tool supply pins: 0 V (expect 12 V or 24 V per gripper rating).

No power → no motion, regardless of “success” in software.

3.3 Step 3: root cause—demo skips voltage init

SDK lists rm_set_end_out_voltage (exact name per your SDK build) to set tool voltage, but the demo’s __init__ only connects the arm—never sets voltage → port stays 0 V.

We added voltage setup (24 V for our gripper) in init and re-ran:

  • Gripper powered up: closed loop, opened to max stroke, noticeable resistance when pushed—closed-loop hold;
  • But set_gripper_pick_on / set_gripper_release still did not open/close on command.

3.4 Step 4: comms—protocol not configured in pendant

Powered but not obeying commands → comms. In the pendant under end-effector settings:

  1. End-effector → communication: baud/check/etc. did not match the gripper manual (115200 required) and was not enabled;
  2. Conclusion: protocol not initialized—the arm’s commands never reached the gripper.

Full picture: the official demo only calls gripper APIs and skips (1) tool voltage and (2) serial protocol—no power, then no parsing.

IV. Fixes: power and communication

4.1 Axis 1: tool-port supply voltage

Gripper needs 12 V or 24 V at the flange—configure first.

Method 1: pendant (quick test)

  1. Pendant → Extensions → end control (no arm connected here—no screenshots from author);
  2. Set end output voltage to 12 V or 24 V (was 0 V)—match gripper nameplate;
  3. Save, reboot arm, re-measure port voltage.
    在这里插入图片描述

Method 2: voltage API in code (automation)

Add voltage setup in __init__ so every connect sets supply:

def __init__(self, ip, port, level=3, mode=2, gripper_voltage=24):
    """
    Initialize and connect to the robotic arm (and gripper), add gripper voltage configuration.

    Args:
        ip (str): IP address of the robot arm.
        port (int): Port number.
        level (int, optional): Connection level. Defaults to 3.
        mode (int, optional): Thread mode (0: single, 1: dual, 2: triple). Defaults to 2.
        gripper_voltage (int, optional): Gripper rated voltage (12/24). Defaults to 24.
    """
    self.thread_mode = rm_thread_mode_e(mode)
    self.robot = RoboticArm(self.thread_mode)
    self.handle = self.robot.rm_create_robot_arm(ip, port, level)

    if self.handle.id == -1:
        print("\nFailed to connect to the robot arm\n")
        exit(1)
    else:
        print(f"\nSuccessfully connected to the robot arm: {self.handle.id}\n")
        # 补充：配置末端端口输出电压为夹爪额定电压
        voltage_result = =self.robot.rm_set_tool_voltage(2)
        if voltage_result == 0:
            print(f"\nSet gripper voltage to 12V succeeded\n")
        else:
            print(f"\nSet gripper voltage failed, Error code: {voltage_result}\n")

4.2 Axis 2: baud rate and serial settings

Gripper talk needs matching baud, data bits, parity, stop bits. The SDK may not expose all of this yet—use the pendant:

  1. End-effector → communication;
  2. From the gripper manual (e.g. 115200, 8N1);
  3. Enter matching values, save, reboot;
  4. Verify: powered gripper, pick/release commands move the jaws.
    在这里插入图片描述
  • Quick lab test: voltage + serial in pendant only;
  • Automation: voltage in code on every connect + one-time pendant serial setup for production runs.

V. Lessons learned

5.1 Root causes

The official gripper demo assumes two prerequisites that it never sets:

  1. Power: actively enable 12 V / 24 V on the tool port—default 0 V means dead gripper;
  2. Comms: baud and framing must match the gripper or commands are ignored.

5.2 Debug order

For “software OK, hardware still”:

  1. Software: calls, parameters, SDK docs;
  2. Hardware: multimeter on supply, wiring, mechanical install;
  3. Comms: pendant protocol page.

5.3 Practical tips

  1. Don’t trust demos blindly—industrial examples often skip init; read the hardware manual;
  2. Measure voltage—faster than log-chasing alone;
  3. Learn the pendant—voltage and baud often live only there until the SDK catches up.

If a future SDK adds serial setup APIs, fold that into init for true one-shot connect-and-run. Arm control is software + hardware + communication—all three must be right before the gripper moves in the real world.

阅读原文