Local Development¶
Local development is useful before submitting work to managed cloud robot cells. There are two loops:
- in-process local execution for fast Python debugging;
- local-container execution to test your Docker image and runtime entrypoint.
If you have access to a real SO-100/101 robot arm, testing armnet though the local development pipeline is recommended to gain familiarity with the process of building Docker images. Uploads of Docker images, model checkpoints, and datasets to Armnet servers and on-premise nodes all take time, making local development the fastest iteration cycle.
In-process local execution¶
For fast iteration without Docker:
uv run python examples/orchestrate_hello_local.py
This runs the @main function directly in your Python process and gives you a
normal debugger experience.
Docker-backed local execution¶
For testing your container before submitting to the cloud:
uv run python examples/orchestrate_so101_local_container.py
Local-container mode is closer to the cloud runtime because it builds a Docker
image and runs armnet-runtime inside the container. It is the right place
to catch missing dependencies, bad Dockerfiles, and runtime import problems.
Debugging local scripts¶
Launch the script with the workspace virtualenv Python:
{
"name": "armnet: hello local",
"type": "debugpy",
"request": "launch",
"program": "${workspaceFolder}/armnet/examples/orchestrate_hello_local.py",
"cwd": "${workspaceFolder}/armnet",
"python": "${workspaceFolder}/armnet/.venv/bin/python",
"envFile": "${workspaceFolder}/armnet/.env",
"console": "integratedTerminal",
"justMyCode": false
}
Debugging containers¶
Container debugging requires debugpy in the image and a published debug port.
For example:
RUN pip install debugpy
CMD [
"python", "-m", "debugpy",
"--listen", "0.0.0.0:5678",
"--wait-for-client",
"-m", "armnet_runtime.cli",
"/app/main.py"
]
Then attach with your IDE to localhost:5678.