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

EROBS application launch

Launch EROBS action servers and the orchestrator, with optional vision, pipettor, joystick, and tracing support.

src.beambot.launch.beambot_bringup.launch · Source

Setup and deployment · Guide · Symbol index

How it is used

ROS launch calls generate_launch_description() to assemble the production action servers and orchestrator. The active beamline configuration supplies planning and IK settings. Vision/Zivid and pipettor components are opt-in; robot and MoveIt startup are managed by the orchestrator lifecycle.

Read this entry when changing which application nodes start or how launch arguments reach them. Function evaluation builds a launch description; the launch service starts its processes.

Start here

Callable

Purpose

generate_launch_description

Assemble the application servers and launch options using the active beamline’s planning and IK settings. Core motion, end-effector, tool-exchange, and orchestrator nodes always launch; vision and pipettor components are disabled by default.

Example

Inspect the available options without starting the application nodes:

ros2 launch beambot beambot_bringup.launch.py --show-args

The workspace and active beamline configuration must already be available.

Functions

generate_launch_description()

Assemble the application servers and launch options using the active beamline’s planning and IK settings. Core motion, end-effector, tool-exchange, and orchestrator nodes always launch; vision and pipettor components are disabled by default.

Entry point · Source

generate_launch_description()

Returns: LaunchDescription containing eight argument declarations, conditional userspace Trace action and nine Node actions. use_sim_time is False for action servers; mock/joystick/batching options go to the orchestrator.

Errors: Config/package/YAML/import errors propagate while generating the description, including tracing dependencies even when disabled. No camera availability check here.

Side effects: Reads configuration during construction. Executing starts ROS processes and optional camera/tracing; use_mock_hardware does not by itself disable the Zivid node. Orchestrator lacks a forced Node name to avoid global remaps affecting its embedded MTC node.