Configuration and deployment boundaries

EROBS separates installation settings from session options. A beamline YAML defines the robot, tools, camera, poses, and scene. Launch arguments select which components run. Robot models, controllers, and planning settings come from the selected ROS packages.

Select the installation

Set BEAMBOT_BEAMLINE_CONFIG before starting EROBS. For example, from the repository root:

export BEAMBOT_BEAMLINE_CONFIG="$(realpath src/beambot/config/cms_drylab.yaml)"

Use the same selection in each terminal that starts the runtime, GUI, or another configuration-dependent client. Beamline selection is an environment variable; it is not a beambot_bringup.launch.py argument.

The repository includes these files under src/beambot/config/:

File	Purpose
`cms_beamline.yaml`	CMS beamline robot settings
`cms_drylab.yaml`	Dry-lab robot endpoint; currently shares CMS tool, pose, scene, and model settings
`lix_beamline.yaml`	Preliminary LIX configuration; requires completion before use

The dry-lab file does not enable mock hardware. Select use_mock_hardware:=true separately, as shown in Run your first task.

Load and apply settings

config_loader.py, under src/beambot/beambot/, provides load_beamline_config(). It reads the selected YAML, validates configured tool payloads and voltages, and returns the settings and source path. Every configured tool needs a finite positive payload_mass and finite payload_cog.x/y/z. tool_voltage accepts 0, 12, or 24 V; omitting it means 0 V. Invalid values are reported together and stop the load.

This is a targeted check, not validation of the entire deployment. Missing selection, missing files, and YAML errors also fail loading; other required fields are checked by their consumers.

A successful load is cached within each process. Callers in that process share the dictionary and must treat it as read-only. The runtime and GUI do not share a live configuration object.

Open the full-size diagram

Restart affected processes after changing the YAML or selecting a different file. Editing the file or exporting a new value does not refresh running processes. The cache-reset helper clears only the loader’s cache, not settings already held by callers.

The GUI also reads beamline settings at startup. It can open without a usable configuration to inspect task JSON, but its robot address and pose registry will be unavailable. Some helper functions supply defaults for isolated use; those fallbacks do not replace the runtime’s required configuration.

See the configuration reference for tool states, payloads, offsets, camera settings, and other fields.

Choose the session components

src/beambot/launch/beambot_bringup.launch.py starts the orchestrator and core task servers. The orchestrator starts the selected robot and MoveIt stack when a task needs it.

Launch argument	Default	Effect
`use_mock_hardware`	`false`	Select mock robot control in the managed robot launch. Camera, pipettor, and other device behavior remain separately configured.
`enable_vision`	`false`	Start Zivid, `vision_scan_server.py`, `vision_task_server.py`, and `sample_pick_place_server.py`.
`enable_pipettor`	`false`	Start the pipettor task server.
`enable_batching`	`true`	Plan compatible consecutive steps in one MTC task.

The sample pick/place server is part of the vision launch group, so disabling vision also removes its use_vision: false pick/place endpoints. The launch reference covers joystick, tracing, and logging options.

Resolve pose and scene paths

resolve_beamline_path() expands ~ and handles resource paths as follows:

Absolute path: use the normalized path directly.
Relative path: search upward from the configuration directory, checking up to ten directories for one containing src/. Resolve against that workspace root; if none is found, use the configuration directory.

For example, poses_file: src/cms/poses.yaml resolves from the workspace root when the YAML is under src/beambot/config/. Moving the YAML outside the workspace can change that result. The resolver constructs a path; it does not check that the resource exists.

Consumer	Lookup behavior
Orchestrator and MCP pose registry; MoveIt and GUI scene loading	Use the shared resolver above
GUI pose panel	Searches upward for an existing file matching `poses_file`; does not use the shared resolver or expand `~`
GUI saved runs	Searches upward for `src/cms/`, then uses `src/cms/runs/`

Use full absolute resource paths for a configuration stored outside the workspace, and verify both GUI and runtime loading. Saved runs retain their CMS-specific lookup. See poses and saved runs.

Model and planner configuration

Three package settings serve different consumers:

Setting	Used for
`robot.moveit_config_package`	Shared planning parameters, kinematics, and joint limits
`grippers.<tool>.moveit_package`	The `robot_bringup.launch.py` launched for that tool
`robot.description_package`	Robot descriptions used by the GUI viewer

Keep these packages consistent with the selected tool. The main launch forwards OMPL, Pilz, and optional STOMP settings to the task servers and orchestrator. Stage planning selects STOMP when its parameters are present, otherwise OMPL. Velocity and acceleration scaling come from the beamline’s robot block, with 0.2 fallbacks.

Adapting another installation

Selecting a different YAML does not replace every site-specific choice:

Camera launch: main bringup explicitly starts Zivid with zivid_optical_frame and presets under src/beambot/config/zivid/. Changing camera.type or camera.frame alone does not change that launch.
Robot launch: CMS bringup still selects CMS packages and contains tool-specific controller and driver branches.
Site data: poses, tool geometry, payloads, camera calibration, and scene geometry must match the installation. The current LIX file lacks active payload values and fails configuration loading, including for mock sessions.

Follow beamline adaptation for the remaining site work and tool and MoveIt lifecycle for how configuration becomes a running robot model.