RoboBuddy Python Docs

The robot object

robot works with the active robot pack. It only creates validated RoboBuddy command JSON; it cannot access serial, files, network, the DOM, imports, packages, hardware SDKs, or system APIs. Select the robot on python.html before running: one Python run has one active robot and cannot switch packs or control SO-101 and LeKiwi concurrently.

Program the SO-101 Follower

On python.html, select SO-101 Follower before running the program. Start in simulation. The browser builds validated commands for so101_follower; it never opens the arm's serial port or imports LeRobot directly.

Joint names, limits, and Home values

Use the six manifest ids below. The displayed ranges are disconnected defaults. A connected session may install narrower, hardware-derived limits, and those active limits take precedence.

SO-101 semantic gripper endpoints are 20 for open and 85 for close.

Move several SO-101 servos in one pose

# Select SO-101 Follower and start in simulation.
robot.move_joints({
  "shoulder_pan": 5,
  "shoulder_lift": -85,
  "elbow_flex": 80,
  "wrist_flex": 68,
  "wrist_roll": 83,
  "gripper": 80,
}, speed=30)

All six targets remain one validated pose command. In simulation, the included values update together as one immediate state change. On hardware, one pose remains one program command and one bridge execution request. A nearby destination uses one LeRobot action map; a larger destination is automatically expanded into measured, bounded action maps. Included joints share one straight joint-space progress fraction per stage, but physical arrival is not guaranteed to be synchronized.

Build a complete pose from planned state

pose = robot.get_joints()
pose["shoulder_pan"] = 10
pose["elbow_flex"] = 25
robot.move_joints(pose, speed=40)

robot.get_joints() returns planned interpreter state. For connected SO-101 hardware it is seeded from fresh measured bridge state when the run starts, then reflects commands planned in that run. It is not a blocking hardware read and does not prove physical arrival.

Send the final absolute target

robot.move_joints({
    "shoulder_pan": 15,
    "elbow_flex": 30,
}, speed=30)
robot.wait(0.5)

The bridge calculates any required intermediate safety stages from fresh measured feedback. Users do not hand-author those increments, and move_joints continues to mean absolute end positions.

Hardware readiness checklist

1. Start the supported SolU-local Python and LeRobot bridge environment.
2. Select the correct controller port and verify the calibration for that arm and port.
3. Confirm that hardware-derived joint limits are loaded and that Home is compatible.
4. Connect the browser to the bridge with the current token.
5. Explicitly arm motion for the current session.
6. Clear the workspace and keep STOP or disarm immediately available.

Position limits do not provide collision avoidance, payload protection, torque/current control, or workspace planning. Finite Python poses use ordinary program ownership. Virtual Leader and Phone Leader are separate continuously refreshed, qualification-gated control modes.

Setup references: local bridge, GitHub Pages to localhost, and SO-101 hardware guidance.

Program the LeKiwi mobile robot

On python.html, select LeKiwi mobile robot. The lekiwi_sim pack is simulation-only in Tier 1: it has a six-joint arm, gripper, and simulated holonomic base, but no physical LeKiwi bridge or hardware adapter.

Joint names, limits, and Home values

The initial preview uses gripper = 85, while robot.home() restores the manifest Home value 50. Semantic open is 20; semantic close is 85.

Move several LeKiwi arm servos in one pose

robot.move_joints({
  "shoulder_pan": 20,
  "shoulder_lift": -15,
  "elbow_flex": 30,
  "wrist_flex": 10,
  "wrist_roll": 20,
  "gripper": 40,
}, speed=40)

The included arm and gripper values update as one simulation command. Application is immediate: speed is not a timed trajectory and does not create synchronized arrival behavior.

Drive the mobile base

robot.drive(
  vx_percent,
  vy_percent=0,
  omega=0,
  seconds=1.0,
  frame="robot",
)

LeKiwi is modeled as a holonomic three-wheel simulator. Linear percentages use the manifest maximum of 1.0 world unit per second. Angular speed is limited to -90..90 degrees per second. Convenience helpers include drive_forward, drive_backward, strafe_left, strafe_right, turn_left, and turn_right.

Sequence the base, then the arm

robot.drive_forward(30, seconds=1.0)
robot.wait(0.2)
robot.move_joints({
  "shoulder_pan": 15,
  "shoulder_lift": -20,
  "elbow_flex": 35,
}, speed=40)

Program the OpenArm V2 Bimanual simulator

Select OpenArm V2 Bimanual · Low Stand + Rotating Base on an operational page. This pack is simulation-only and exposes a programmable base_yaw, two independent seven-joint arm chains, and two independent pinch grippers.

Move both arms in one absolute pose

robot.home()
robot.move_joint("base_yaw", 45, speed=30)
robot.move_joints({
    "left_j1": 20,
    "left_j2": -7,
    "left_j4": 0,
    "right_j1": -20,
    "right_j2": 7,
    "right_j4": 0,
}, speed=40)

Control the grippers independently

robot.open_gripper(side="left", speed=25)
robot.close_gripper(side="right", speed=25)
robot.open_gripper(side="both", speed=25)

# The grippers are also ordinary manifest joints.
robot.move_joint("left_gripper", 12, speed=25)
robot.move_joint("right_gripper", 36, speed=25)

Program all 29 joints in the kinematic G1 simulator

Select Unitree G1 29-DoF on an operational page. Every leg, waist, arm, and wrist joint is available through robot.move_joint(...) and robot.move_joints({...}). The complete joint list and pinned mesh provenance are in the G1 simulator guide.

robot.home()
robot.set_posture("wide_stance", seconds=0.8)
robot.walk("forward", steps=3, step_length=0.08, speed=45)
robot.turn(90, seconds=1.2)
robot.set_posture("work_reach", seconds=0.8)
robot.pick_nearest("right_hand")
robot.release("right_hand")
# Or run the authored walk, grab, return preview:
robot.run_demo()

Know what each programming method guarantees

Tier 1 support matrix

Current execution boundaries

SO-101 and LeKiwi troubleshooting

The same material remains available as a maintainable source reference in the SO-101 and LeKiwi programming guide.

The arm object

arm is a RoboBuddy classroom object. It is available automatically in the Python editor. Do not import it. It remains as a backward-compatible alias for Arduino arm programs.

arm.move_joint("shoulder", 120, speed=45)

arm.move_arm(
  base=90,
  shoulder=110,
  elbow=70,
  wrist_rot=90,
  wrist_tilt=100,
  gripper=80,
  speed=45
)

arm.home()

arm.wait(0.5)

arm.gripper_open()
arm.wait(0.3)

arm.gripper_close(speed=45)

arm.smooth_move("shoulder", 65, 120, seconds=1.2)

arm.save_pose("pickup")

arm.go_to_pose("pickup", speed=45)

arm.emergency_stop()

print(arm.get_angles())

Legacy arduino_arm names and ranges

These names belong to the Arduino Arm. SO-101 and LeKiwi use the six manifest ids listed in the Robot API section.

Writing Gemini requests on the Gemini page

The Gemini page uses Google's google.genai style, but it runs through a RoboBuddy classroom shim. Your code captures one client.models.generate_content(...) request, the page sends it with the Session API Key field and Model selector, then response.text is replayed into your code.

from google import genai

client = genai.Client()
response = client.models.generate_content(
  model="gemini-3.5-flash",
  contents="Explain one safe wave motion for RoboBuddy."
)
print(response.text)

from google import genai

client = genai.Client()
response = client.models.generate_content(
  model="gemini-3.5-flash",
  contents=[
    {
      "role": "user",
      "parts": [
        {"text": "Plan a safe classroom robot motion."},
        {"text": "Use short steps and avoid joint limits."}
      ]
    }
  ]
)
print(response.text)

from google import genai

types = genai.types
client = genai.Client()
response = client.models.generate_content(
  model="gemini-3.5-flash",
  contents="Return a short JSON plan for a safe wave.",
  config=types.GenerateContentConfig(
    temperature=0.2,
    thinking_config=types.ThinkingConfig(thinking_budget=0),
    response_mime_type="application/json",
    response_schema={
      "type": "object",
      "properties": {
        "summary": {"type": "string"},
        "steps": {
          "type": "array",
          "items": {"type": "string"}
        }
      },
      "required": ["summary", "steps"]
    }
  )
)
print(response.text)

from google import genai

client = genai.Client()
response = client.models.generate_content(
  model="gemini-3.5-flash",
  contents="Use the selected page image to name objects the arm should avoid."
)
print(response.text)

from google import genai

client = genai.Client()
response = client.models.generate_content(
  model="gemini-3.5-flash",
  contents="Create a safe three-step wave for RoboBuddy."
)
print(response.text)
roboadmin.use_response(response.text)

These examples adapt Google's Gemini API patterns for the RoboBuddy page. For full SDK behavior outside this lab, see Google's Generate content API, structured output guide, and image understanding guide.