Environments and Tasks

Every job you submit names a task. The task tells Armnet what you want the robot to do, and it is also how your job gets routed: the orchestrator looks up which cells are set up for that task and sends the job to one of them.

Tasks are grouped into environments. An environment is the physical scene a cell is built around — the objects on the table, how they are scored, and how they get put back for the next episode. Two tasks in the same environment run on the same hardware setup and differ only in the goal.

execute(
    image=image,
    embodiment="lerobot/so-101",
    task="push_green_button",   # the task slug
    timeout_seconds=600,
)

The environments

Environment	Scoring	Reset between episodes	Availability
BusyBox	Automatic — the panel reads its own state	Automatic — the arm stages the next episode	24/7
Manual	A human operator watches and scores the rollout	A human operator restages the scene	Scheduled, see below

BusyBox scores every one of its tasks itself. Its reset motions are taught one at a time, so a task without one yet waits for an operator between episodes instead of running unattended; its page says where that stands.

Manual environments

manual is not a piece of equipment — it means a human being is in the loop. An operator sets the scene up by hand before each episode, watches the rollout, and presses Success or Fail to score it.

That makes manual tasks the flexible option: anything a person can stage and judge can become a manual task, including deformable objects, multi-step household jobs, and scenes with no sensors in them at all.

Manual tasks are not available around the clock

A manual job needs an operator on site, so it does not start the moment you submit it. Manual jobs are queued and run within the next 7 days. Submit with detach=True and collect the result later rather than blocking your process on it.

Current manual tasks:

Task slug	What the robot is asked to do
block_stack	Stack the colourful blocks on top of each other
cable_clip	Push the DisplayPort cable into the cable holder on the white block
cable_unclip	Remove the power cable from the cable holder
eye_drops_to_basket	Put the eye drops into the basket
eye_drops_to_shelf	Put the eye drops on the shelf
fold_tea_towel	Fold the brown tea towel
insert_big_rings	Insert the big rings
insert_candle	Insert the candle inside the lantern and close the door
open_lamp_door	Hold the pink lamp still with the left arm and open the door with the right gripper
ring_insert	Insert the colourful ring into the central wooden peg
tool_insert	Insert the missing tool into the empty slot on the toolbox
tool_removal	Remove the small middle tool (3/8 extension bar, 75 mm) from the toolbox
transfer_cube	Transfer the cube between the arms and drop it into the white basket

Automated environments

An automated environment brings its own instrumentation, so it does not need a person watching. Each one supplies two things the platform calls into:

• A completion checker. The environment reads its own physical state and decides whether the goal was met, so every episode is scored the same way and scored immediately. No operator verdict, no video review afterwards.
• A reset mechanism. Between episodes the environment puts itself back into a valid starting state, usually by running a stored motion plan on the arm.

Because nothing in that loop waits for a human, automated environments are built for continuous use: you can queue hundreds of episodes and they will run overnight. This is what you want for benchmarking a policy or for a training run that evaluates checkpoints as they land.

BusyBox is the first automated environment. More will follow, each with its own page in this section.

When an automated environment still asks for help

An automated reset needs a motion the arm has been taught, and teaching one takes a person driving the arm through it once. Where that has not happened yet, or where the environment cannot read a control it needs, it falls back to asking an on-site operator and the job waits at that point. This is temporary per task, not a property of the environment.

Finding the tasks that exist right now

The tables in this section are a guide; the orchestrator database is the source of truth, and the set of tasks grows. Ask the API for the current list:

import httpx
from armnet_client._config import api_key, orchestrator_url

headers = {"X-Armnet-Api-Key": api_key()}
print(httpx.get(f"{orchestrator_url()}/tasks", headers=headers).json())
print(httpx.get(f"{orchestrator_url()}/embodiments", headers=headers).json())

Reading the base URL from the SDK rather than hard-coding it means your script keeps working if the endpoint moves.

A job submitted with a task slug that is not on that list is rejected with HTTP 400, so it fails immediately rather than sitting in a queue.

To check whether a cell for your task is online before you submit:

from armnet_client import OrchestratorClient

status = OrchestratorClient().get_cell_status(
    embodiment="lerobot/so-101",
    task="push_green_button",
)
print(status)

Choosing an embodiment

embodiment says which robot the task runs on, and it has to match the cell:

• lerobot/so-101 — a single SO-101 arm.
• lerobot/bimanual_so101 — a dual-arm SO-101 cell.
• lerobot/arx5 — an ARX5 arm.

Two-arm manual tasks such as open_lamp_door and transfer_cube only run on lerobot/bimanual_so101. Submitting one without setting the embodiment routes it to a single-arm cell and the run fails fast.

BusyBox is on a single-arm cell, so use lerobot/so-101 for every BusyBox task. Its *_bimanual slugs cannot be scheduled at the moment; see the BusyBox page.