Commands and startup scripts

Run EROBS commands from the checkout after sourcing ROS, the installation overlay, and the beamline configuration. See setup if the host is not ready.

Core entry points

Command	Effect
`ros2 launch beambot beambot_bringup.launch.py`	Starts the core task servers and orchestrator; vision/Zivid and pipettor require explicit enable flags
`ros2 run mtc_gui mtc_gui_client`	Opens the primary operator GUI
`ros2 run beambot beambot_client.py /path/to/task.json`	Reads a JSON file, submits `MTCExecution`, prints feedback, and waits for the result
`python -m beambot.agent`	Starts the experimental direct agent; see its current endpoint and credential requirements
`./setup.sh`	Imports dependencies and runs rosdep on a prepared host; includes system-package operations

The JSON file client sets full_json; it does not expose a CLI switch for dry_run. Use a client that explicitly populates the action field for plan-only preview. The file client’s initial JSON check verifies syntax; the orchestrator performs task-language validation.

Choose a startup wrapper deliberately

Script under `utils/`	ROS bridge	Recording	Important default
`start_robot.sh`	No	Yes	Real hardware unless launch arguments change it
`start_robot_nobag.sh`	No	No	Same application defaults
`start_mcp.sh`	Yes	Yes	Writes launch output to `/tmp/beambot_launch.log`
`start_mcp_nobag.sh`	Yes	No	Same log path, no experiment bag
`sim_start_mcp.sh`	Yes	Yes	Adds `use_mock_hardware:=true`; vision and pipettor remain off unless explicitly enabled
`start_ursim.sh`	Separate URSim helper	No EROBS bag	Runs `ur_client_library`’s UR5e simulator launcher

The five robot/MCP wrappers source Jazzy and the workspace installation. Each requires an existing BEAMBOT_BEAMLINE_CONFIG and forwards its arguments to main bringup.

The MCP wrappers also wait for the bridge and capture launch output. MCP client/server registration is a separate step; see MCP and agent integration.

For example, a restricted mock launch without experiment recording is:

./utils/start_mcp_nobag.sh \
  use_mock_hardware:=true enable_vision:=false enable_pipettor:=false

This still creates ROS processes and a log. Restrict introductory requests to a tool-free MoveTo. Mock UR control does not make arbitrary device operations offline.

Discover the current ROS graph

On the prepared ROS host, these commands inspect interfaces and connections without submitting a motion goal:

ros2 node list
ros2 action list -t
ros2 action info /beambot_execution
ros2 interface show beambot_interfaces/action/MTCExecution

Missing child actions can be explained by disabled launch groups. In particular, disabling vision also disables the legacy sample server. The orchestrator starts MoveIt when a task first needs it.

Survey, capture, and performance tools

scripts/survey_mapping/ contains live capture orchestration and an offline merge path. The live survey’s --dry-run suppresses recording but still performs robot movements; it must not be used as a no-motion checker. Use the survey guide for the actual procedure.

src/beambot/scripts/capture_octomap.py derives scan/capture steps from a saved run, sends goals, triggers captures, and optionally saves a map. Its --self-check exercises its planning helper; normal invocation is a device workflow.

The performance tracing scripts start a traced run and summarize captured CTF events. Main bringup exposes enable_tracing, trace_session_name, and orchestrator_log_level. Install the tracing dependencies and select an output session before collecting timing data.

Shutdown and cancellation

The robot wrappers (start_robot.sh, start_robot_nobag.sh) run the launch in the foreground, so Ctrl+C reaches it directly and it stops its nodes in order; start_robot.sh also stops its bag recorder. The MCP wrappers still run the launch as a background job and stop it from an exit handler. After stopping one, check that no EROBS processes remain. Process teardown is not a substitute for checking the state of a physical operation. The file client attempts goal cancellation on Ctrl+C; the orchestrator’s response is path-dependent. Follow execution controls for pause/cancel semantics and recovery.