> ## Documentation Index
> Fetch the complete documentation index at: https://docs.generalrobotics.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# make_robot

> Make a remote robot and connect to it via the signaling server

```python theme={null}
from grid_nexus_client import make_robot
```

```python Signature theme={null}
make_robot(
    robot_name: str,
    program=None,
    debug: bool | None = None,
    *,
    restart: bool = False,
    zenoh_config: str | os.PathLike[str] | Mapping[str, object] | None = None,
    enable_monitor_ws: bool | None = None,
    timeout: float | None = DEFAULT_CONNECT_TIMEOUT_SECS,
) -> RemoteRobot | RemoteDeployment
```

Make a remote robot and connect to it via the signaling server.

Returns a `RemoteRobot` for direct command dispatch, or a
`RemoteDeployment` if a `program` is provided (staged execution mode).
A remotely invoked program declares a `Robot` parameter and receives the
returned deployment in that slot; programs without a `Robot` parameter
use the standalone `grid_nexus_program.run_program` path.

In direct mode, the robot runtime builds the robot on the first
`make_robot()` of a robot session and reuses it for every later call in
that session, from any notebook or script. `restart=True` shuts that
robot and its navigation down and builds a fresh one without ending the
session. The robot is released when the session ends. When this call
joined an existing dev session (`zenoh_config` or a discovered one),
`RemoteRobot.shutdown()` closes only this client; when it opened the
session itself through signaling, `shutdown()` ends that session and
releases the robot. A staged deployment always builds its own robot, so
`restart` requires direct mode.

The signaling URL comes from `GRID_USER_SIGNALING_URL` when set — the GRID
CLI always exports it for the active cluster — and otherwise from the
`GRID_TARGET_ENV` profile defaults.

Streaming is inferred from the mode: off for direct/dev mode, on for
staged/deploy mode. Disconnects and re-raises on any connection failure.

`enable_monitor_ws` controls the in-process Rust websocket snapshot
broadcaster that serves the monitor on `127.0.0.1:8765`.

`zenoh_config` connects directly to an existing TUI-owned dev session
without opening a signaling websocket. It is supported only for direct/dev
mode, not when `program` is provided. Pass either a path to the TUI
session config file or the same combined `{"player": ..., "edge": ...}`
mapping. The former bare Player object is not accepted. When omitted, an
active dev session for `robot_name` (the config the GRID CLI writes on
`robot connect` / `session start robot`) is discovered automatically;
with no active dev session the signaling path is used.

When `debug` is omitted, it is enabled for staged/deploy connections
where `program` is provided and disabled for direct/dev connections.
It controls only cloud model debug-image streaming; pass `debug=False`
to disable those streams for a deployment. Native Rust/zenoh log verbosity
is controlled separately through `RUST_LOG` and defaults to warnings.

For `enable_monitor_ws`:

* `None` (default): best-effort. Start if possible, log and continue on
  failure (e.g. port already taken by another `make_robot()`).
* `True`: required. Propagate any failure so the caller knows.
* `False`: skip entirely.

Setting `GRID_NEXUS_CLIENT_DISABLE_MONITOR_WS=1` in the environment
behaves like `enable_monitor_ws=False` when the kwarg is left as
`None`.


## Related topics

- [USBCamera](/python-api/cameras/usbcamera.md)
- [Robot interface](/python-api/robot-interface/overview.md)
- [grid-nexus-client](/python-api/grid-nexus-client/overview.md)
- [Python APIs](/python-api/overview.md)
- [Your first skill](/get-started/first-skill.md)