Work in progress: this documentation is still being written and reviewed. Check details against the source code.

Beamline adaptation

The beamline configuration selects models, tools, camera settings, poses and scene data. Adapting EROBS to another site also requires calibrated data and updates to the CMS-specific paths and tool branches described below.

What is present today

Area

Contents

Interpretation

CMS

Beamline and dry-lab YAMLs, model/planning packages, calibration assets, poses, tasks and saved runs

Shared resources; distinct robot endpoints.

LIX

Separate beamline YAML, Hand-E model/planning packages and a pose-registry placeholder

Adaptation material; complete deployment is unverified

PDF

Container, driver, MoveIt and Bluesky launch scripts

Historical/site-specific deployment material; continued use unverified

Select a deployment through BEAMBOT_BEAMLINE_CONFIG. The main configuration loader requires this environment variable. The configuration reference explains its fields and path resolution.

The adaptation boundary

Review each part of the beamline YAML against the new installation:

Configuration area

Site choices

Robot

Arm planning group, joint order, robot/model packages and network endpoint

Tools

States, controllers, payload, communication settings and tip frames

Camera

Adapter type, frame and marker dictionary

Vision targets

Marker IDs, offsets or rack grids, and movement sequences

Pose and scene paths

Site data files

Joint order is part of the interface. Named poses store positional six-joint values; changing the joint list without converting those values changes their meaning. Likewise, a target named sample_scan_1 is not portable merely because both beamlines use a UR5e.

For a new site using existing tool types:

  1. Review a copy of the beamline configuration in a development checkout.

  2. Supply the corresponding pose, scene and calibrated model data.

  3. Inspect the code that loads those settings for remaining site assumptions.

The GUI still resolves saved runs to src/cms/runs, and model launches retain structural tool branches. Selecting another YAML does not make every part of the application site-neutral. CMS selects the dedicated ur_with_zivid_2fg7.urdf for its 2FG7 viewer.

LIX-specific differences

LIX defines Hand-E rather than CMS’s full interchangeable-tool set. Its MoveIt directory includes OMPL and Pilz configuration, while CMS also has STOMP. The shared planner loader permits STOMP to be absent. The complete LIX stack remains unverified.

The LIX Hand-E configuration leaves payload_mass and payload_cog commented out. The shared configuration loader requires those values for every configured tool, including in mock sessions, so the current file fails at configuration loading. Supply measured and reviewed values before commissioning. The LIX robot calibration also includes a replacement placeholder, and src/lix/poses.yaml is comments-only. Replace these placeholders with measured calibration and taught poses.

PDF and external dependencies

scripts/pdf-launch-scripts/ contains a talker/listener communication exercise, UR-driver launchers, Hand-E/MoveIt launchers, a sample-movement server launcher and a BSUI launcher. Several names and image references reflect an earlier container deployment. Retain them as reference material until their users and versions are established. They are not the default CMS startup path.

External drivers and camera repositories have their own branch refs in the .repos manifests. Record their actual commits when commissioning a beamline. Record exact commits alongside the ROS distribution, Zivid SDK, serial settings, and tool controller version.

Acceptance for another installation

An adaptation review should cover:

  • Model agreement with TF, controller joint names, payload and tool communication.

  • Taught pose ordering, camera calibration and scene geometry.

  • Task parsing and client discovery.

Begin with isolated configuration and mock checks, then use the site’s approved hardware commissioning procedure. Treat GUI display, planning preview and real motion as separate evidence.

A new tool type or detector goes beyond configuration and needs code changes; the module map shows where tool, launch, and perception code live.