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

Function and method reference

Use this reference when extending EROBS or investigating how a component works. Each module introduces its purpose and usage before the detailed function contracts.

Choose a subsystem below and follow its Start here links. If you already know a function name, use the symbol index. For operating the platform, start with the operator guides.

Browse by subsystem

Task execution

Task validation, pose resolution, batching, action dispatch, and execution controls. Includes run recording and performance tracing.

7 modules · 60 entries

Motion planning

MTC stages, planner selection, trajectory execution, and plan caching. The CMS Servo node provides a separate continuous-command path.

5 modules · 57 entries

Tools and end effectors

Gripper control, sample handling, pipettor commands, and tool exchange, including the local 2FG7 driver and ePick launch configuration.

15 modules · 60 entries

Perception and mapping

Camera acquisition, feature detection, motion-target calculation, and scene mapping. Includes survey capture and offline point-cloud merging.

19 modules · 128 entries

Operator GUI

Task editing, pose storage, execution controls, chat, and robot visualization. The ROS bridge connects the Qt interface to topics, actions, and services.

16 modules · 317 entries

Clients and integrations

Task submission from the CLI and Bluesky, EPICS-to-ROS utilities, and MCP/agent clients. Task-building helpers return JSON for a separate submission step.

8 modules · 96 entries

Setup and deployment

Beamline configuration, launch descriptions, tool-specific MoveIt startup, and process cleanup. Docker helpers build and publish images.

9 modules · 49 entries

Examples and demos

The teaching orchestrator, motion and logging stages, and a Bluesky example. Demo tasks use a separate schema; motion examples can operate the robot.

11 modules · 39 entries

The module map shows which files implement each feature. The architecture guides explain how the subsystems work together.

Reading an entry

Module pages explain how the code is used, identify key callables, and group methods under their owning classes. Internal callbacks and helpers follow the main methods. All entries remain searchable and directly linkable.

The role beside each signature tells you how the callable is used:

Role

Meaning

Entry point

A starting point for a workflow or for tracing its implementation. Follow the module’s usage guidance before calling it.

Extension hook

A method implemented or overridden by subclasses.

Lifecycle

Construction, initialization, cleanup, or shutdown.

Callback

Called by ROS, Qt, a timer, or another framework event.

Method / function

A regular operation used by the surrounding code.

Internal helper

Supporting implementation logic.

These labels describe usage, not a guarantee of a stable public API. An underscore alone does not determine whether a method is an extension hook.

Signatures, defaults, and annotations come from source. Parameter descriptions explain expected inputs; error notes describe validation and recovery. Uncaught exceptions propagate unless the entry describes recovery. Side-effect notes identify state changes, I/O, camera capture, and robot motion where applicable.

Referenced in source lists statically identified references. It can omit dynamic dispatch, inherited methods, GUI string lookups, ROS clients, and external callers. No listed references does not mean a function is unused.

self and cls in Python signatures refer to the current instance and class. Examples that require a running application state their context.