Robot Skill Language (RSL)

• Robot Skill Language (RSL) is a family of abstractions that defines robot capabilities as reusable, parameterized skills bridging primitive commands and complex tasks.
• Various implementations use statechart-based DSLs, JSON recipes, and command-based syntaxes to offer flexible representations and execution semantics.
• RSL frameworks integrate natural language grounding, compiler checks, and runtime verification to enhance modularity and robustness in robot programming.

Searching arXiv for papers related to "Robot Skill Language" and adjacent formulations. Tool call: arxiv_search({"query":"Robot Skill Language skill-based robot programming language statecharts skills tasks LightRocks", "max_results": 10, "sort_by": "relevance"}) Robot Skill Language (RSL) denotes a class of representations that encode robot capabilities as reusable, parameterized skills situated between primitive controller commands and full task descriptions. Across the literature, RSL is not realized as a single canonical notation. Instead, it appears as a UML/P Statechart-based domain-specific language in LightRocks, as JSON schemas paired with task-parameterized movement primitives in CLASP, as a command-based DSL with compiler-verified correctness in NRTrans, as a standardized hierarchy of micro and macro skills grounded in Building Information Modeling (BIM) for construction robots, and as a practical skill library plus neutral JSON control recipes for manufacturing systems (Thomas et al., 2014, Knauer et al., 6 Jun 2026, Chen et al., 26 Aug 2025, Yu et al., 2 Sep 2025, Lohi et al., 2024). In all of these forms, the central aim is to expose robot behavior as composable skill units with explicit parameters, conditions, and execution semantics, while reducing direct dependence on controller-specific code.

1. Foundational abstraction: elemental actions, skills, and tasks

A foundational RSL formulation is provided by LightRocks, which defines three core abstractions: Elemental Actions (EAs), Skills, and Tasks. EAs are the smallest executable units and map almost directly to robot or device commands. Skills are reusable capabilities modeled as nets of EAs with explicit transitions, pre/post conditions, and outcomes. Tasks are higher-level compositions of skills that represent complete operational goals such as “grasp and screw” or “grasp and plug.” The language is explicitly layered: lowest-level skills and EAs are created by domain experts; mid-level skill composition is performed by shop-floor technicians; and higher-level process or task sequencing may be generated by planning systems or reordered by non-experts (Thomas et al., 2014).

The formal definitions in LightRocks make this hierarchy explicit. An elemental action is

$$\mathrm{EA} := (\mathrm{Device}, \mathrm{DeviceCommand}, \alpha, p),$$

with $$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$, a robot command of the form $$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$, stop condition $\alpha$, and return values $p$ that update the environment model. Skills and tasks are defined as

$$\mathrm{Skill} := (\mathrm{Nodes}^*, \mathrm{Transitions}^*, \mathrm{StartNodes}^*, \mathrm{StopNodes}^*)$$

and

$$\mathrm{Task} := (\mathrm{Skills}^*, \mathrm{Transitions}^*, \mathrm{StartSkills}^*, \mathrm{StopSkills}^*).$$

LightRocks also introduces a Generic Action Component,

$\mathrm{GAC} := (l, A, B, P, N, e),$

which unifies all layers through level identifiers, start and end conditions, parameters, child components and transitions, and an execution command (Thomas et al., 2014).

The same paper embeds robot-control details directly into these abstractions. A task frame is defined as

$$\mathrm{TF} := \{T, \mathrm{Ref}, \mathrm{Link}\}, \quad T \in \mathbb{R}^{4 \times 4},$$

and a goal frame as

$\mathrm{GF} := \{T, \mathrm{Ref}\}.$

Impedance parameters satisfy

$$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$0

while stop conditions are Boolean-valued functions

$$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$1

This design makes the skill abstraction broad enough to include compliant motion, multi-sensor behavior, perception calls, and tool operations without collapsing the upper layers into controller API details (Thomas et al., 2014).

2. Representational forms and surface syntax

RSL implementations differ sharply in surface form even when they share the same conceptual role. Documented forms include Statechart-based models, JSON recipes, JSON tool definitions, command sequences, and state-transforming skill tuples (Thomas et al., 2014, Lohi et al., 2024, Knauer et al., 6 Jun 2026, Chen et al., 26 Aug 2025, Yu et al., 2 Sep 2025).

Representation form	Example systems	Core elements
Statechart-like DSL	LightRocks	<Skill>, <Task>, <ElementalAction>, guards, outcomes
Neutral JSON recipe	Manufacturing skill programming system	skill sequence, part IDs, poses, paths, feature files
JSON tool definition	CLASP	skill_name, parameters, primitive_skills, preconditions, postconditions
Command-based DSL	NRTrans	FORWARD NUMBER;, APPROACH OBJECT;, GRASP OBJECT;
Hierarchical skill tuple	Construction skill standardization	$$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$2

LightRocks uses a Statechart-like textual representation with explicit tags such as <Skill> Name, <Task> Name, and <ElementalAction> Name, as well as parameter declarations and guarded transitions. Representative fragments include skills such as Screwing with guards like [TorqueZ > 0.32] -> CloseGripper, and tasks such as GraspingAndScrewing whose transitions propagate outcomes such as IsGrasped, TargetReached, and NotScrewed (Thomas et al., 2014).

By contrast, the manufacturing-oriented system described in “Programming of Skill-based Robots” does not provide a formal DSL with a grammar, static type system, or algebra of operators. Its practical RSL is realized through a reusable skill library and a task “control recipe” serialized as JSON. That recipe encodes at least one skill and, for each skill, stores type, order number, part ID, target ID or IDs, and concrete parameters such as approach, action, and departure poses, path points, or localization parameter files (Lohi et al., 2024).

CLASP makes the language layer explicit as VLM-generated JSON tool definitions. A skill schema contains skill_name, explanation, example_usage, parameters, primitive_skills, object_order, preconditions, and postconditions. The paper’s auto-generated PickAndPlace schema illustrates a typed interface in which parameter names such as object_to_pick and object_to_place are bound to detected scene entities, while phase-level subskills specify frame associations for Pick and Place (Knauer et al., 6 Jun 2026).

In the construction setting, the syntax is less about surface notation than about a standardized executable schema. A micro skill is formalized as

$$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$3

where $$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$4 are preconditions, $$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$5 are effects, $$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$6 are BIM-derived parameters, $$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$7 is the controller, $$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$8 is termination, and $$\mathrm{Device} \in \{\mathrm{Robot}, \mathrm{Tool}, \mathrm{PerceptionUnit}\}$$9 is an optional objective. Serial composition is written

$$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$0

with validity determined by precondition/effect matching (Yu et al., 2 Sep 2025).

NRTrans is the most conventional DSL among the surveyed systems. It is command-based, each statement is a keyword plus optional parameters, and each statement terminates with a semicolon. The language includes commands such as FORWARD NUMBER;, TURNLEFT NUMBER;, PERCEIVE;, APPROACH OBJECT;, GOTO NUMBER, NUMBER;, and GRASP OBJECT; (Chen et al., 26 Aug 2025).

3. Execution semantics, compilation, and runtime architectures

RSLs differ not only in syntax but also in how they define execution semantics. In LightRocks, all action components are mapped to UML/P Statecharts. States correspond to EAs, skills, or tasks depending on the abstraction layer; transitions encode state changes with events, optional guards, and optional actions; and hierarchical states capture skills composed of EAs or tasks composed of skills. Entry actions, exit actions, and do-activities map directly to device commands such as robot motions, tool operations, and perception queries. The toolchain is built with MontiCore and the UML/P code generation infrastructure, which compile the models to Java code running against a domain adapter and a state runtime environment. Generated states inherit from abstract base classes and implement defineChildStates(), defineTransitions(), performByEntry(), and canBeEntered() (Thomas et al., 2014).

CLASP provides a different form of semantics: each skill is a pair $$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$1, where $$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$2 is a trained task-parameterized kernelized movement primitive (TP-KMP) and $$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$3 is a VLM-generated schema. Demonstrations are projected into local task frames using

$$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$4

and, at execution time, local Gaussian predictions are transformed back to the global frame as

$$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$5

Composition is defined by covariance-weighted product-of-Gaussians fusion:

$$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$6

Composition is only accepted if the compatibility constraint on non-overlapping dominance regions is satisfied, with margin $$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$7. Executed motion uses Cartesian impedance control with

$$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$8

This gives the skill language a continuous probabilistic semantics rather than a purely symbolic one (Knauer et al., 6 Jun 2026).

NRTrans makes correctness guarantees compiler-centric. RSL rules are defined via regular expressions and compiled with ANTLR-generated lexer and parser components. Parsing uses LL(1) analysis to produce an abstract syntax tree, and a custom code generator traverses the tree depth-first to emit Python programs bound to ROS-based robot interfaces. The compiler checks lexical and syntactic correctness, parameter arity and types, and the rule that numeric parameters must be positive. The associated debugger returns semantic-intuitive error categories such as keyword, identifier, number, command, parameter, quantity, and semicolon errors, with messages including “Keywords should be lowercase.” and “The number of parameters is illegal.” (Chen et al., 26 Aug 2025).

A more expansive interpretation of RSL appears in “Language to Rewards for Robotic Skill Synthesis,” where the intermediate language is a parametric reward function rather than a symbolic command stream. The skill interface is

$$(\mathrm{flag}, \mathrm{TF}, \mathrm{GF}, \mathrm{JV}, \mathrm{ST}, \mathrm{DA})$$9

and the controller solves a receding-horizon optimization problem

$\alpha$0

Here the “skill language” is the space of residual terms, weights, and target parameters generated by the two-stage Reward Translator and executed by MuJoCo MPC or MJPC (Yu et al., 2023).

4. Natural-language grounding and skill interpretation

A major recent development is the use of RSL as an intermediate layer between natural language and executable robot behavior. In fleet selection, the paper “To Select or not to Select, that is the Question: Distilling Robot Skill Prediction into a Small Ensemble” operationalizes this as a fixed capability taxonomy

$\alpha$1

with each task mapped to a binary vector $\alpha$2. Two sentence encoders are ensembled by averaging sigmoid probabilities,

$\alpha$3

On a stratified 200 task dataset, the ensemble reaches 83.5% exact-match accuracy, 96.3% Hamming score, and Macro F1 of 0.941, with per-skill F1 scores of 0.981 for Fly, 0.905 for Legs, 0.899 for Wheels, 0.943 for Hands, 0.939 for Under Water, and 0.978 for Surface Water. The paper explicitly interprets this capability-vector mapping as an RSL interpreter layer for heterogeneous fleets (Bong et al., 20 May 2026).

CLASP grounds language through tool-calling with a pretrained multimodal VLM, Qwen3-VL-32B-Instruct. During execution, the system provides all skill schemas as tool definitions, the user command, and a workspace image. The VLM performs skill matching, binds parameters to detected objects, and, when no single skill suffices, proposes candidate compositions in terms of primitive phases and their frame associations. If neither direct selection nor valid composition is possible, the system explains the capability gap and requests a targeted kinesthetic demonstration, after which a new TP-KMP and schema are added to the library (Knauer et al., 6 Jun 2026).

The construction-robot architecture treats natural language at a different level: it extracts micro-skill sequences from crowdsourced online tutorials and uses LLMs for macro chaining. Its prompt constrains outputs to a fixed action dictionary, enforcing one canonical action word per step. The system compares Bayesian Network, Hidden Markov Model with Bayesian inference, LSTM, and GPT-4 variants for next-action prediction, and reports that GPT-4o achieved 100% success on test chains, while GPT-4o-mini and HMMBI scored 0% on the given test. Natural language therefore functions not only as a user interface but also as a source of executable long-horizon task structure (Yu et al., 2 Sep 2025).

Language Guided Skill Discovery (LGSD) uses language more indirectly, as a semantic metric for discovering and indexing skills. A prompt $\alpha$4 defines which semantic distinctions matter; a rule-based annotator converts states into textual facts; a deterministic LLM produces descriptions; and SBERT embeddings define a cosine-based language distance

$\alpha$5

A skill-conditioned policy then maximizes a WDM-linked objective under a Lipschitz constraint, and a text-to-skill inference network $\alpha$6 enables zero-shot natural-language skill utilization (Rho et al., 2024).

5. Applications and empirical record

LightRocks is evaluated on assembly operations including screwing a wooden screw into a cube and plugging electrical parts onto a top hat rail. The screwing task involves localize, grasp, approach, and screw with impedance control; a representative condition is to stop spinning when torque about 0.32 Nm is exceeded, then open the gripper, rotate the hand back, and continue until the $\alpha$7-position is reached or a stop condition triggers. Error outcomes such as NotGrasped and NotScrewed enable retries or safe termination. In the plugging scenario, the system uses RGB-D data and geometric model matching to estimate object pose and update the environment model. The paper reports that programming such a task took less than an hour, and that tasks could be easily reordered while skills were reused with minor changes (Thomas et al., 2014).

The manufacturing-oriented skill-library system reports practical feasibility in two settings. In CAD-based assembly, the hardware consisted of a KUKA Agilus with a Schmalz suction gripper, a Zivid 2 3D camera, and VTT 3D vision; the user created an assembly task by sequencing skills and selecting target parts in the CAD model, generated the JSON recipe, and executed the task successfully, though no quantitative metrics were reported. In collaborative path scanning, the hardware consisted of an NDI Polaris Vega XT 6D tracker with a mechanical pointer, a Zivid One 3D camera, and a UR10e robot with pointer tool. The operator digitized scan path points, localized the work object, transformed the points to the object frame, and generated a recipe with scan localized; the robot then demonstrated the scan trajectory after the work object was moved (Lohi et al., 2024).

CLASP reports validation on a 7-DoF torque-controlled DLR SARA manipulator with a Robotiq gripper and a static RGB-D camera. Object generalization across five YCB objects reached 90.9% (40/44), pose generalization with automatic vision poses reached 79.3% and with manual poses 100%, skill composition across four pick objects and four place objects reached 100% (16/16), active learning capability-gap detection reached 95% (19/20), and grasp-and-insert composition after learning Insert Ring reached 73.3% (11/15). Motion learning required only 2–5 kinesthetic demonstrations per skill, with 4 in most experiments (Knauer et al., 6 Jun 2026).

The construction RSL is demonstrated in a long-horizon drywall installation experiment on a full-scale industrial robotic manipulator. The execution chain is Start → Prepare → Plan → Cut → Install → Nail → Finish. BIM parameters are streamed from Rhino to ROS via Flask, and the reported average end-to-end BIM→ROS semantic transmission latency is 0.067 seconds over 10 trials. The experiment includes robot requests for tool changes, warnings during cutting, holding behavior during nailing, and human confirmation messages such as “PREPARATION CONFIRMED” and “please press Enter when finished” (Yu et al., 2 Sep 2025).

The reward-based interface in “Language to Rewards for Robotic Skill Synthesis” spans 17 tasks on a simulated quadruped robot and a dexterous manipulator. The approach reportedly solves 90% of the designed tasks, while a Code-as-Policies baseline using primitive skills achieves 50%. The paper also reports real-robot validation on a robot arm, where complex manipulation skills such as non-prehensile pushing emerge through the interactive reward-specification system (Yu et al., 2023).

6. Conceptual boundaries, misconceptions, and open issues

A common misconception is that RSL denotes a single standardized textual language. The surveyed literature shows otherwise: LightRocks is a Statechart-based DSL; NRTrans is a command-based DSL; the manufacturing system is a skill library plus JSON recipe; CLASP uses JSON tool definitions; the fleet-selection work uses flat capability vectors; and the reward-synthesis system treats reward parameterizations as the intermediate interface. This suggests that RSL is better understood as a family of abstractions for skill specification, composition, and execution rather than as one fixed grammar (Thomas et al., 2014, Chen et al., 26 Aug 2025, Lohi et al., 2024, Knauer et al., 6 Jun 2026, Bong et al., 20 May 2026, Yu et al., 2023).

Another misconception is that RSL is equivalent to simple task sequencing. In several systems, the language carries much richer semantics: LightRocks encodes guards, entry and exit conditions, and hierarchical reuse; CLASP assigns continuous probabilistic semantics through TP-KMP and covariance-weighted fusion; LGSD defines semantic diversity through language-distance and a WDM-linked intrinsic reward; and the construction framework grounds skill parameters in BIM and object-state transitions (Thomas et al., 2014, Knauer et al., 6 Jun 2026, Rho et al., 2024, Yu et al., 2 Sep 2025).

The principal limitations are heterogeneous and reflect the diversity of RSL forms. LightRocks notes plans to “allow more concurrency on Statechart level,” does not present formal verification or large-scale empirical studies, and does not publish a full textual grammar (Thomas et al., 2014). The manufacturing system lacks pre/postconditions and continuous evaluation in skills, restricts task-level composition to linear sequencing, and supports collaborative programming only for continuous-path skills (Lohi et al., 2024). CLASP currently validates composition primarily for pairwise combinations, assumes static scenes, depends strongly on perception quality, and requires training a 6D pose estimator for new object categories (Knauer et al., 6 Jun 2026). The fleet-level capability interpreter uses a fixed six-skill flat taxonomy and therefore omits payload capacity, endurance, dexterity, terrain specificity, and other routing-relevant attributes (Bong et al., 20 May 2026). NRTrans limits correctness to compiler-verified lexical, syntactic, and basic semantic validity, while explicitly deferring advanced control flow and dynamic environment monitoring (Chen et al., 26 Aug 2025). The construction framework remains centered on a micro-skill vocabulary primarily oriented toward pick-and-place-like operations, retains manual pipeline elements, and avoids real-time task-level inference for reliability (Yu et al., 2 Sep 2025). LGSD is demonstrated in Isaac Gym simulation and depends on prompt quality, language grounding, and pseudometric assumptions for $\alpha$8 (Rho et al., 2024). The reward-based interface depends on morphology-specific templates and a predefined family of residual terms, which constrains the space of expressible skills (Yu et al., 2023).

Taken together, these limitations indicate that RSL research is split across at least three unresolved fronts: representational standardization, verification depth, and grounding fidelity. Some systems emphasize modular symbolic composition, others continuous motion semantics, others compiler guarantees, and others natural-language interoperability. A plausible implication is that future RSL work will continue to combine these strands rather than replace one with another.