Source-linked AI summary
A New Skill Based Robot Programming Language Using UML/P Statecharts
Ulrike Thomas, Gerd Hirzinger, Bernhard Rumpe, Christoph Schulze, Andreas Wortmann
TL;DR
Uncertainty and the complexity of programming compliant robot arms make reusable robot programming difficult for non-experts. LightRocks organizes robot behavior as Statechart-modeled skills and tasks, with generated code and a graphical editor. Two test cases were solved successfully, and the paper demonstrates reuse and intuitive task programming.
Problem
Uncertainty, sensor use, and the stiffness and damping settings required for compliant LWR motions make programming complex and limit it to domain experts; reusable composition tools are missing.
Source: §I · p. 1Method
LightRocks models primitive actions, skills, and tasks at different abstraction levels using UML/P Statecharts, with experts defining skills and non-experts combining them into tasks.
Source: §III · p. 2, B. Elements of LightRocks · pp. 2–3, C. Describing the Elements of… · p. 3Results
The authors report that both test-case scenarios were solved successfully and that defining assembly processes and tasks was intuitive, including for someone not very familiar with robotics.
Source: §VI · p. 6Takeaways & Limitations
LightRocks supports reuse across abstraction levels, and workers can reorder tasks or reuse skill models by changing few elements.
Source: §VI · p. 6, §V · p. 6
Abstract
from arXiv · showhide
This paper introduces the new robot programming language LightRocks (Light Weight Robot Coding for Skills), a domain specific language (DSL) for robot programming. The language offers three different level of abstraction for robot programming. On lowest level skills are coded by domain experts. On a more abstract level these skills are supposed to be combined by shop floor workers or technicians to define tasks. The language is designed to allow as much flexibility as necessary on the lowest level of abstraction and is kept as simple as possible with the more abstract layers. A Statechart like model is used to describe the different levels of detail. For this we apply the UML/P and the language workbench MontiCore. To this end we are able to generate code while hiding controller specific implementation details. In addition the development in LightRocks is supported by a generic graphical editor implemented as an Eclipse plugin.
I. INTRODUCTION
Flexible robot assembly remains difficult because uncertainty requires sensing, while compliant LWR motions require tuning stiffness and damping as well as positions. LightRocks addresses limited program reuse and composition with a three-layer, Statechart-based language and supporting tools.
I. INTRODUCTION
- Sensor, object-position, and tolerance uncertainties complicate flexible robot assembly, while LWR programming also requires motion-specific stiffness and damping settings.The paper says this complexity, especially with more sensors, leaves compliant-arm programming to domain experts.Source: §I · p. 1
- Existing program reuse depends on individual experts, and tools for reuse and composition across levels of detail are missing.Source: §I · p. 1
- LightRocks uses three Statechart-based abstraction layers: experts code skills, non-experts combine them into tasks, and assembly sequences can be generated and instantiated by other systems.Source: §I · p. 1
- UML/P Statecharts models are generated into Java through MontiCore, while separating the DSL from the robot interface and providing a generic Eclipse editor.The authors report two test cases for the programming environment.Source: §I · p. 1
II. RELATED WORK
Related work seeks intuitive programming of compliant robot actions through task-frame formalisms, skill primitives, Statecharts, and object-centered approaches. The paper positions Statecharts as suitable for LWR modeling and code generation, while noting prior adaptations and demonstrations across robot settings.
II. RELATED WORK
- Task-frame formalism became popular for compliant actions, while skill primitives were developed into nets for complex robot tasks,.Task-frame implementations also include Cartesian force-feedback robots,,.Source: §II · p. 1
- For LWRs, task-frame definitions need modification; the paper favors Statecharts as familiar modeling constructs suited to code generation.Source: §II · p. 2
- Prior alternatives include Statechart-coded peg-in-hole search, sensor-integrating iTASC object-space programming –, and symbolic object-centered programming.Source: §II · p. 2
III. DESCRIPTION OF THE LightRocks DSL
LightRocks organizes robot programming into abstraction levels, from primitive commands to skill nets. This hierarchy supplies the basis for defining the language elements.
III. DESCRIPTION OF THE LightRocks DSL
- The hierarchy starts with instantiated actions that contain primitive commands.Source: §III · p. 2
- Instantiated actions are combined into skill nets, in a structure comparable to skill-primitive or manipulation-primitive nets,.Source: §III · p. 2
- The authors define LightRocks elements based on this hierarchy and requirements of the LWR.Source: §III · p. 2
A. The Interface to the LWR
The LWR interface sends motion commands to its controller over TCP/IP and supports joint-space and Cartesian motion. Commands specify frames, impedance settings, and sensor-based stopping conditions.
A. The Interface to the LWR
- Each LWR motion command is sent to the controller over TCP/IP and may use joint-space or Cartesian-space motion.Source: A. The Interface to the LWR · p. 2
- Cartesian commands specify a task frame and a goal frame, whose reference objects need not be the same.The task frame includes a transform, reference, and link; the goal frame includes a transform and reference.Source: A. The Interface to the LWR · p. 2
- Cartesian impedance commands include six stiffness and six damping values.For joint-space commands, stiffness and damping are specified for each joint.Source: A. The Interface to the LWR · p. 2
- A stop condition maps sensor values to true or false through a conjunction or disjunction of measurable values.Source: A. The Interface to the LWR · p. 2
B. Elements of LightRocks
LightRocks builds robot behavior from elemental actions into skills and tasks. Experts define skills, while less-specialized workers can combine them into tasks without detailed controller or device knowledge.
B. Elements of LightRocks
- Elemental Actions (EAs) are the smallest LightRocks actions, mapping nearly directly to a motion interface while also allowing access to tools and perception services.An EA assigns a device a command, can stop when a condition triggers, and can update the environmental model with returned values.Source: B. Elements of LightRocks · p. 2
- A skill is a net of EAs connected by transitions, with at least one start node and one stop node.For example, object recognition, approach, and impedance-controlled grasping can be composed into a skill that handles pose uncertainty.Source: B. Elements of LightRocks · p. 2
- Skill transitions have pre- and post-conditions, and each node's returned values update the environmental model between those conditions.Source: B. Elements of LightRocks · p. 3
- A task is a net of skills with start and stop skills; robot experts define skills, while shop-floor workers can combine or reorder them into tasks.Task transitions have the same behavior as skill transitions, allowing exception handling in task compositions.Source: B. Elements of LightRocks · p. 3
C. Describing the Elements of LightRocks with the UML/P
LightRocks specifies its DSL with UML/P and models skills and tasks using Statecharts. This mapping reuses UML/P syntax and code-generation tooling across abstraction levels.
C. Describing the Elements of LightRocks with the UML/P
- UML/P provides the DSL's formal semantics, and its Statecharts model system behavior as states and transitions with conditions and actions.States can be hierarchical; transitions connect source and target states and may include stimuli, actions, preconditions, and postconditions.Source: C. Describing the Elements of… · p. 3
- Because skill and task nets resemble Statecharts, LightRocks maps tasks, skills, and elemental actions to states, and directed arcs to transitions.Start and stop conditions map to entry and exit action preconditions, respectively.Source: C. Describing the Elements of… · p. 3
- The hierarchical Statechart illustrates UML/P Statechart language elements used in this mapping.Source: Figure 2 · p. 3, C. Describing the Elements of… · p. 3
D. Generic Component
The Generic Action Component unifies LightRocks elements across abstraction levels for code generation. It combines conditions and parameters with child components or a concrete execution command.
D. Generic Component
- A Generic Action Component is a tuple (l, A, B, P, N, e) describing an action component's level, start and end conditions, parameters, children and transitions, and execution command.The execution command is undefined when the component has children; otherwise, it can specify a concrete method call.Source: D. Generic Component · p. 3
- Its parameters are typed and named, with an optional default value.Source: D. Generic Component · p. 3
- A child-component set and its transitions can connect child or parent start and end conditions, with values assigned to target parameters.Source: D. Generic Component · p. 3
- The execution command is a concrete method call; components with children instead define execution through those child components.The component acts like a method declaration with conditions governing when it starts, is interrupted, or finishes.Source: D. Generic Component · p. 3
IV. CODE GENERATION
LightRocks maps Action Components to UML/P Statecharts and generates code from those models. Separate runtimes support state behavior and connect domain interfaces to robot APIs.
IV. CODE GENERATION
- Each Action Component maps to a UML/P Statechart, from which executable code is generated.States and transitions are generated as classes that inherit from the state runtime's base class.Source: §IV · pp. 3–4, Figure 5 · p. 4
- Generated code uses a state runtime for hierarchies, transitions, and state import or extension, alongside an adapter between the domain interface and robot API.Different adapters can support different robot APIs and be switched without changing the models.Source: §IV · p. 4, Figure 4 · p. 4, Figure 5 · p. 4
- The screwing Skill figure shows two different steps during the skill.Source: Figure 6 · p. 4
- Runtime classes follow UML/P Statechart concepts closely, allowing most elements to be translated one by one.Generated states define child states, transitions, entry actions, and entry conditions where given.Source: §IV · p. 4
V. CASE STUDIES
The case studies demonstrate LightRocks at task and skill levels through screwing and rail-assembly examples, including skill-based assembly completed in under an hour.
V. CASE STUDIES
- The wooden-screw test presents its task-level grasping-and-screwing model in Fig. 7 and its screwing-skill implementation in Fig. 8.The test uses a wooden screw and cube from wooden toys.Source: §V · p. 4, Figure 7 · p. 5, Figure 8 · p. 5
- After localizing and gripping the screw, the robot moves it into an approach pose above the cube, then down the screw-axis until torque exceeds about 0.32 Nm.The gripper opens, the robot turns its hand back about −180◦, and screwing repeats until a certain position in z-axis is reached or the stop-condition triggers.Source: §V · p. 4
- The second case study plugs electrical parts onto a top hat rail using perception-based localization and impedance control to reduce uncertainty.The assembly sequence contains three tasks; Fig. 9 shows the sequence and Fig. 10 shows a task implementation.Source: §V · pp. 4, 6, Figure 9 · p. 5, Figure 10 · p. 6
- The rail-assembly task took less than an hour to program, and predefined skills could be reused while tasks were reordered.Changing the execution sequence required reordering tasks only.Source: §V · p. 6
VI. CONCLUSIONS
The authors report that LightRocks successfully solved two LWR test cases and supports reusable, intuitive programming across abstraction levels. They describe portability and extensibility as design benefits, while identifying real assembly-line evaluation and greater Statechart concurrency as future work.
VI. CONCLUSIONS
- LightRocks successfully solved two test scenarios with the LWR, and the authors report efficient implementation of Tasks, Skills, and Elemental Actions.They describe assembly-process and task definition as intuitive even for people with limited robotics familiarity.Source: §VI · p. 6
- The authors report reuse across abstraction levels and target platforms, with generic actions and UML/P supporting adaptation to other robots.For Cartesian force-feedback robots, they state that only small changes are needed; LightRocks can also be extended for additional sensors or motion specifications.Source: §VI · p. 6
- Evaluation in real assembly lines, more Statechart concurrency, and comparison with sequential function charts remain future work.Source: §VI · p. 6