Glossary

A reference for robotics terms you'll see across the docs and the Solarian-specific concepts the framework introduces. Each entry links to the full page when one exists.

Robotics terms

ACT (Action Chunking Transformer)

An imitation-learning policy that predicts a chunk of the next k actions at once with a transformer, and averages overlapping chunks with temporal ensembling. solarian-policy-lerobot trains it with the lerobot_act trainer. See Policies and learning.

Actuator

A hardware component that produces motion or force — a motor, a servo, a linear stage, a gripper. In Solarian, an Actuator is a Component attached as a class attribute on a Module.

Body

A rigid mechanical link in a robot's structure. In Solarian, "body" is used informally; the framework's primary structural unit is a Module (e.g. an arm, a gripper, a base).

Bus

The physical or logical channel a host computer uses to talk to one or more hardware devices: a USB serial bus, a CAN bus, a Dynamixel bus, an Ethernet socket. In Solarian, a ComponentBus is the Python object that wraps this protocol.

Calibration

The process of mapping raw hardware values (encoder ticks, ADC counts) to physically meaningful units (radians, meters). Solarian stores motor calibration on each actuator in the module yaml (real_range_min / real_range_max / center_offset / drive_mode) and provides solarian calibrate / write-robot-calibration to manage them. center_offset is the encoder-zero shift (Present = raw − offset); the Feetech/Dynamixel register is still named Homing_Offset. See Calibration.

Cartesian space

A frame defined by (x, y, z, rx, ry, rz) describing position and orientation of an end effector. Contrast with joint space. solarian-ur5 exposes both representations as separate actuators on the same arm.

Control loop

The repeating sequence of read sensors → decide action → write actuators. In Solarian, every Module has its own control loop running at cfg.frequency, and every Controller has a control loop running at cfg.fps.

Degree of freedom (DoF)

An independent axis of motion. A 6-DoF arm can position its end effector in any pose; a 1-DoF gripper can only open or close.

Diffusion policy

A policy that generates a short trajectory of actions by starting from random noise and removing predicted noise step by step, conditioned on the observation. It learns the whole distribution of demonstrated actions, so each sample commits to one way of doing the task. The UMI policy in the tutorials is one. See Policies and learning.

End effector

The tip of a manipulator — the gripper, the tool, the camera. Cartesian-space targets typically refer to the end-effector pose.

Frame

A coordinate system attached to a body. Common frames: world frame, base frame, end-effector frame, camera frame. Most actions in Solarian are expressed relative to a known frame declared by the module.

Frequency / Rate / FPS

How often a loop runs, in Hz. Solarian uses frequency for module loops and fps for the robot's observation publish rate and the controller's control rate.

Gripper

A simple end effector with one or two DoFs that grasps objects. Often packaged as its own Module (e.g. solarian-umi-gripper).

Imitation learning / Behavior cloning

Learning a policy from demonstrations: a person does the task, the robot records observations and actions, and a network learns to output the demonstrated action for each observation. Behavior cloning is its simplest form, plain supervised learning on (observation, action) pairs. Tutorial 5 records demonstrations and trains one.

Inverse kinematics (IK)

The math that turns a desired end-effector pose into the joint angles needed to achieve it. Cartesian-space actuators in Solarian rely on the underlying driver to compute IK on the robot side.

Joint

A connection between two bodies that allows constrained relative motion (rotational, prismatic). Each joint is typically driven by a single actuator.

Joint space

A representation of a robot's configuration as a vector of joint values, one per joint. Contrast with Cartesian space.

Kinematics

The geometry of motion — how joint values map to end-effector poses (forward kinematics) and back (inverse kinematics).

Markov decision process (MDP)

The standard model of a decision problem: states, actions, dynamics that give the next state from the current state and action, and a reward. Markov means the next state depends only on the current state and action. A robot sees observations, a part of the state, so its real problem is partially observed. See Policies and learning.

Policy

The decide step of the control loop as a function: an observation goes in, an action comes out. A policy is either written by a person as code or learned as a neural network from data. In Solarian a policy runs behind a PolicyServer that skills call.

Pose

A combined position + orientation, usually (x, y, z, rx, ry, rz) or a 4×4 transformation matrix.

Proprioception

A robot's sense of its own state — joint positions, joint velocities, end-effector pose. Distinct from exteroception (cameras, force sensors).

Reinforcement learning (RL)

Learning a policy from reward by trial and error: the policy acts, a reward scores the result, and training changes the policy to collect more total reward, the return. Most robot RL trains in simulation and transfers the policy to hardware. See Policies and learning.

Sensor

A hardware component that produces data — a camera, an IMU, a force sensor, an encoder. In Solarian, a Sensor is a Component attached to a Module.

Servo

A device that combines an actuator and a sensor in one package — a motor that knows its own position. Solarian's Servo class inherits from both Actuator and Sensor.

Teleoperation (teleop)

A controller-driven mode where a human directly drives the robot — via keyboard, joystick, or a "leader" arm — to demonstrate behavior or to manually accomplish a task.

Trajectory / Waypoint

A trajectory is a time-parameterized path through configuration space; a waypoint is a single point on that path. Solarian's modules support waypoint scheduling via ActionType.SCHEDULE_L / SCHEDULE_J and a built-in TrajectoryInterpolator (pose or scalar). See Scheduling Waypoints. In learning, a trajectory also names a recorded sequence of observations and actions, o₀, a₀, o₁, a₁, …; an episode in a dataset is one.

Vision-Language Model (VLM)

A multimodal model that consumes images and text and returns text. Used by Solarian's AI Controller to decide which skills to start or stop.

Vision-Language-Action model (VLA)

A VLM trained further to output robot actions: camera images, an instruction, and the joint state go in, and actions come out, either as action tokens or as a continuous chunk from an action expert. See Policies and learning.

Solarian terms

Action

The typed schema of a single command sent from the controller to the robot each tick. Contains an action_type and either per-module sub-actions or arbitrary data. See Actions.

Action handler

A method decorated with @action_handler(action_type) on a Robot or Module. The framework dispatches incoming actions to the matching handler. See Registering handlers.

Action queue

A queue per module, implemented as ModuleActionQueue. On the Robot it is what incoming actions are written into and what the module's run loop drains. A Skill owns one per module it commands, and pushes there rather than returning actions to its host. Shared memory when it has to cross a process boundary, an in-process ring when it does not.

Action type

An integer tag on every Action that controls how it's dispatched. Built-ins are STOP, MODULE_ACTION, MOVE_*, SERVO_*, SCHEDULE_*, RESTART_PUT, plus START_SKILL and STOP_SKILL, which serve both the think process → controller channel and the controller → robot one. Custom types live at >= ActionType.CUSTOM_START. See Action types.

ActuatorBus

A ComponentBus subclass that adds write(), enable_torque(), disable_torque(), and calibration writing. One per hardware port.

ActuatorField

A class-attribute descriptor on a ModuleAction that binds an action field to a Data reference on a Robot actuator.

AI Controller

A Controller subclass that runs a dual-process System 1 / System 2 architecture: fast reactive Skills plus a slow VLM-driven ThinkProcess. See AI Controller.

BusClient / BusServer

When two modules share a hardware port, the Robot starts a BusServer in the parent process and gives each module a BusClient proxy. From the module's perspective the bus still looks like a normal ModuleBus.

CalculatedField

An Observation field whose value is computed from other fields by a Processor. Declares its inputs, processor, output, and where it runs (ExecutionPlace.SERVER or ROBOT).

CameraBus

A SensorBus whose reads are frames. Adds the archive tap — every frame read is also handed to the episode encoder, stamped with when the sensor exposed it. Base class for OpenCVCameraBus and PiCameraBus. See Recording.

Component

The smallest addressable unit of hardware: an Actuator, a Sensor, or a Servo. See Components.

ComponentBus

The abstract base for buses. Subclasses: ActuatorBus, SensorBus (and below it CameraBus), plus per-vendor implementations (UR5Bus, DynamixelBus, …).

Controller

The node that decides what the robot does — keyboard teleop, learned policy, AI controller. Subclasses either start Skills and let the base control_step() merge what those skills emit, or override control_step() outright. See Controllers.

ControllerConfig

Pydantic model for conf/controller.yaml (fps, tps, agent, policy_path, device, headless, connection, modules; system2_* only for the legacy AIController).

AgentHarness

The AI controller: a planner model that calls the controller's tools, and a monitor model that watches them. Enabled by agent: in conf/controller.yaml. See AI Controller.

Tool

A skill class plus the params a controller binds, as the AI controller's planner sees it. Declared in Controller.tools. See AI Controller.

Data

The Pydantic-typed wrapper around every value flowing through Solarian. Subclasses include PosData, SpeedData, ImageData, BoundingBoxData, TimestampData. See Data classes.

ExecutionPlace

Enum (CONTROLLER, ROBOT, SERVER) naming which runtime owns a skill, and which host runs a CalculatedField's processor.

Event

Something that happened, at a point in time — a key went down, a button was clicked. Emitted by a Module, queued, and drained by the host on its control tick. Continuous state stays an Observation instead. See Events.

Event handler

A method decorated with @event_handler(event_type) on a Controller. All handlers for a type run, so a subclass adds to the base class's reaction rather than replacing it. See Events.

Event type

An integer tag on every Event. Built-ins are KEY_DOWN, KEY_UP, BUTTON_DOWN, BUTTON_UP. Custom types live at >= EventType.CUSTOM_START. See Events.

Hydra

The configuration framework Solarian uses to compose YAML. See Project Configs.

KeyboardModule

The default input Module on every Controller. Emits KEY_DOWN / KEY_UP events and publishes the set of held keys as a local observation. Runs INLINE.

ModuleAction

The per-module schema bound to a Module's actuators via ActuatorField descriptors. See Actions.

ModuleBus

Per-module wrapper that groups one or more ComponentBus instances (one per hardware port) and routes calls.

ModuleObs

The per-module schema bound to a Module's sensors via SensorField and CalculatedField descriptors. See Observations.

Module

Anything connected to the runtime — an arm, a gripper, a camera, a keyboard. Produces observations and events, and/or consumes actions. How it is scheduled is a separate property, its ExecutionMode. See Modules.

ModuleConfig

Pydantic model for conf/modules/<module_name>.yaml (frequency, actuators, sensors, interpolator_type, …). Modules can extend it via config_class.

Observation

The typed schema of every sensor reading the robot publishes per frame. Groups ModuleObs instances by module name. See Observations.

ObservationBuffer

Every module's history of recent observations, and the one place a skill reads state from. Backed by shared memory when the module runs in its own process, by a plain in-process ring when it runs inline on its host. Read the newest sample with latest() or a window with last_k(n).

Plug-in

A standalone solarian-<name> Python package that provides one or more hardware drivers (modules, actuators, sensors, buses). See Plug-ins.

RelayServer

The middle node of Solarian's architecture. Forwards actions from controllers to robots and observations back. See Server.

Robot

The on-robot node that owns hardware. Subclasses attach Modules as class attributes. See Robots.

RobotConfig

Pydantic model for conf/robot.yaml (fps, img_compression_quality, connection).

Runner

The machinery that actually schedules a Module or Skill: ProcessModuleRunner, ThreadModuleRunner, or InlineModuleRunner, picked by make_runner() from the target's ExecutionMode. All three drive the same worker_setup / worker_tick / worker_teardown protocol and expose the same start / stop / is_alive / join interface, so callers never learn which they got.

SensorBus

A ComponentBus subclass for sensors. Sensors that produce frames use CameraBus below it.

SensorField

A class-attribute descriptor on a ModuleObs that binds an observation field to a Data reference on a Robot sensor.

ServerConfig

Pydantic model for conf/server.yaml (connection, img_compression_quality).

Settings

The project's settings.py registry that holds ROBOT_CLASS, CONTROLLER_CLASS, SERVER_CLASS. Loaded lazily as solarian.conf.settings. See Project Settings.

Skill

A self-contained, restartable behavior the Controller launches in response to an event or a VLM decision. Consumes observations and events, produces actions. See Skills.

ExecutionPlace

Enum (CONTROLLER, ROBOT, SERVER) naming which runtime owns a Skill. Remote placements are started by enqueuing an Action rather than launching locally.

ExecutionMode

Enum (PROCESS, THREAD, INLINE) naming how a Module or Skill is scheduled. It is a property, not a base class: a Runner reads it at launch time, so the same class can run in its own process in production and inline in a test.

SkillStatus

Enum (IDLE, RUNNING, COMPLETED, FAILED, STOPPED) reported by skills via the shared SkillStatusBuffer.

System 1 / System 2

The naming Solarian uses for its dual-process AI architecture. System 1 = fast reactive control loop running Skills. System 2 = the AI Controller's planner, which calls those skills as tools.

ThinkProcess

The legacy AIController's System 2 process (solarian.core.ai.old): queried a VLM each tick to decide which skills to start or stop. Replaced by the agent: harness.

ZeroMQ

The networking library Solarian uses for all controller ↔ relay ↔ robot communication. PUSH/PULL for actions, PUB/SUB for observations.

See also

• Browse the Core Concepts section for full pages on each Solarian concept.
• The Overview walks through the whole architecture from the top down.