Motion Statecharts in Robotics

• Motion Statecharts are formal models that express motion commands, constraints, sensor feedback, and termination conditions as executable state machines.
• They support a hierarchical abstraction by mapping elemental actions to skills and tasks, thereby isolating device-specific details while enhancing reusability.
• They enable concurrent, event-driven execution in robotics and rail systems, ensuring robust safety and adaptive constraint management across various control levels.

Motion Statecharts are statechart-based formalisms for representing motion as an executable combination of motion commands, constraints, sensing, guards, monitors, and termination conditions. In LightRocks, Elemental Actions, Skills, and Tasks are mapped to UML/P Statecharts so that impedance-controlled manipulation with the DLR Lightweight Robot Arm can be programmed at multiple abstraction levels while hiding controller-specific details (Thomas et al., 2014). In Giskard, Motion Statecharts are introduced as an executable symbolic representation that closes the Motion Execution Gap by allowing the arbitrary arrangement of motion constraints, monitors or nested statecharts in parallel and sequence over a unified differentiable kinematic world model (Stelter et al., 12 May 2026). A related statechart literature on rail motion emphasizes the disciplined “eventization” of continuous movement into occupancy events, timers, and guards, providing a broader conceptual context for motion-oriented statechart design (Al-Fedaghi, 2021).

1. Research lineages and conceptual scope

The term appears explicitly in two robotics contexts with different emphases. The 2014 LightRocks work presents a domain-specific language for robot programming in which a Statechart like model is used to describe three levels of detail: Elemental Actions, Skills, and Tasks. The purpose is to separate concerns so that domain experts define robust motion skills while shop-floor technicians compose tasks from those skills, with code generation mediated by UML/P and MontiCore (Thomas et al., 2014).

The 2026 Giskard work uses Motion Statecharts for a different but related problem: the disconnect between high-level semantic task descriptions and executable robot motion. There, Motion Statecharts are not primarily a programming-language frontend for device APIs, but an executable symbolic representation in which Motion Tasks, Monitors, and nested statecharts determine which constraints are active in a jerk-bounded lMPC at each control cycle (Stelter et al., 12 May 2026).

The railcar case study does not introduce a robot programming language under the same name, but it develops a statechart-oriented treatment of motion in which continuous travel through segments and terminals is discretized into event partitions such as segment entry, reservation, dwell timing, and departure authorization. Its importance lies in showing that motion control can be rendered tractable by converting continuous evolution into discrete triggers, timers, and guards, with hierarchy and orthogonality capturing interacting subsystems such as motion, doors, signaling, and braking (Al-Fedaghi, 2021).

A plausible implication is that “Motion Statecharts” names a family of motion-centric statechart practices rather than a single standardized notation. What is shared across the literature is the encoding of motion behavior as stateful, guarded, executable structure, with explicit treatment of sequencing, branching, and state-dependent activation.

2. Core abstractions and representational units

In LightRocks, the representational hierarchy is explicit. Elemental Actions are tiny commands addressed to devices such as Robot, Tool, and Perception Unit. Skills are nets of Elemental Actions that deliver capabilities such as grasping, screwing, plugging, or pushing. Tasks are nets of Skills that encode task sequences, including error handling and branching. The paper also references a process/plan level where tasks are ordered by an assembly planner (Thomas et al., 2014).

The formal definitions are given as tuples:

$EA := (Device, DeviceCommands, A, p)$

where $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$, $A$ is a stop condition, and $p$ are return values that update the environmental model. For Robot, the device command is

$(flag, TF, GF, JV, ST, DA)$

with $flag$ selecting Cartesian or joint space. Skills and Tasks are defined as

$$Skill := (Nodes^*, Transitions^*, StartNodes^*, StopNodes^*)$$

$$Task := (Skills^*, Transitions^*, StartSkills^*, StopSkills^*)$$

and LightRocks unifies these through the Generic Action Component

$(l, A, B, P, N, e), \quad N = \{C, T\}$

where $l$ is a level identifier, $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$0 is a parameter set, $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$1 and $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$2 are start and end conditions, $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$3 is a set of child Action Components, $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$4 their transitions, and $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$5 the execution command when the component is not composed from children (Thomas et al., 2014).

In Giskard, the basic units are different. An MSC node can be a Motion Task, associated with one or more task functions that remain active while the node is active, or a Monitor, which has no task functions and instead observes predicates, sensor conditions, or task satisfaction. Each node contains two finite state machines: an Observation FSM with the three-valued states True, False, and ?, and a life cycle FSM with states taskInactive, taskActive, taskOnHold, and taskDone. Nodes can contain nested isolated statecharts called MSC Templates, and templates support both sequential and parallel composition (Stelter et al., 12 May 2026).

The following comparison captures the principal units without collapsing the distinct semantics of the frameworks:

Context	Primary units	Composition style
LightRocks	Elemental Actions, Skills, Tasks	Hierarchical composition through Generic Action Components
Giskard	Motion Tasks, Monitors, MSC Templates	Arbitrary sequencing and parallelization of tasks, monitors, and nested statecharts
Rail motion modeling	Motion, Doors, Signaling/Interlocking, Power/Brake	Orthogonal components synchronized by events and guards

This difference in units is substantive. LightRocks centers motion programming around reusable, parameterized robot actions and their assembly. Giskard centers execution around constraint activation and monitoring. The railcar model centers on decomposition of a transportation system into concurrent behavioral regions.

3. Statechart semantics, hierarchy, and eventization

LightRocks projects its Action Components to UML/P Statecharts because the nets of Elemental Actions, Skills, and Tasks correspond closely to states and transitions. A state has a name, an invariant $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$6, an entry action, an exit action, and an activity. A transition has a stimulus, an optional action, an optional precondition, and an optional postcondition. Tasks, Skills, and Elemental Actions are projected onto states; directed arcs become transitions; start and stop conditions map to the preconditions of entry actions and to exit actions; child Action Components become nested states; and parameters are declared in a code segment attached to the Statechart. The system relies on UML/P Statecharts’ formal semantics; enabledness arises when a stimulus occurs and the precondition holds, entry actions execute on entering states, and exit actions execute when leaving states (Thomas et al., 2014).

Giskard retains the statechart idea but changes the execution semantics substantially. Its life cycle transitions are governed by ternary logical expressions over Observation FSM states of nodes at the same hierarchy level. Sequential templates activate child $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$7 when child $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$8 observes True; parallel templates activate all children simultaneously and succeed when $$Device \in \{\text{Tool}, \text{Robot}, \text{Perception Unit}\}$$9 children observe True. EndMotion and CancelMotion are terminal states. Because the node semantics separate “what is observed” from “whether the task is active,” the formalism decouples satisfaction status from activation status in a way not present in conventional flat FSM encodings (Stelter et al., 12 May 2026).

The railcar literature emphasizes a complementary issue: motion must be “eventized” before statechart semantics can govern it effectively. Segment entry and exit events set Occupied and Unoccupied flags; a train in segment $A$0 sets Approaching to block departures from parking; dwell time in the terminal is represented by a 90 s timer; scenario-driven events such as arrivingAck, platformAllocated[number], waitEnter, parked, departReq(dir), exitAllocated, and alertStop become statechart events; and threshold crossings on kinematic signals such as $A$1, $A$2, and $A$3 provide additional triggers. Orthogonality is central here: Motion, Doors, Signaling/Interlocking, and Power/Brake execute in parallel regions and synchronize by broadcast events and shared guards (Al-Fedaghi, 2021).

A common misconception is that motion statecharts are merely graphical sequencing diagrams. In the cited systems they are executable semantic artifacts: they determine state residency, transition enabledness, monitor status, and, in Giskard, the exact set of constraints imposed on the optimizer in each control cycle.

4. Motion specification, parameterization, and control realization

In LightRocks, the robot interface exposes both joint-space and Cartesian motions under an impedance controller. A Cartesian motion command contains the task frame

$A$4

the goal frame

$A$5

and stiffness and damping vectors

$A$6

Joint-space motions use seven joint variables and per-joint stiffness and damping. The stop condition is a Boolean function mapping sensor values to true or false and can be composed as a conjunction or disjunction over measurable signals. This formulation makes motion, sensing, and tool control first-class statechart content while preserving parameterization for reuse across targets, velocities, tolerances, thresholds, and timeouts (Thomas et al., 2014).

Giskard replaces controller-specific command tuples with a world-centric, differentiable kinematic world model. The model is a kinematic tree including robot and articulated environment, defined by sets of links $A$7, joints $A$8, and symbols $A$9, where $p$0 contains controllable DoFs and their derivatives up to third order and $p$1 contains non-actuated variables treated as constants by the controller. Each joint transform is

$p$2

implemented as CasADi symbolic expressions for automatic differentiation. Task spaces are differentiable mappings

$p$3

and task functions take equality or inequality form:

$p$4

Execution is realized by a jerk-bounded lMPC formulated as a quadratic program with velocity and slack penalties, box bounds on velocity and jerk, a semi-implicit Euler system model over a short horizon, and task functions enforced as linear constraints on the integrated Jacobian. The horizon is typically less than $p$5s, qpSWIFT is used, and the implementation enables 100 Hz control on a high-performance CPU (Stelter et al., 12 May 2026).

The contrast is instructive. LightRocks expresses motion in terms of parameterized robot API calls embedded in hierarchical statecharts. Giskard expresses motion in terms of world-referenced constraint activation over robot-and-environment kinematics. Both are executable, but they sit at different points in the stack: one is close to device-level skill programming, the other to semantic constraint realization.

5. Monitoring, robustness, safety, and concurrency

Robustness in LightRocks is encoded primarily through guards, stop conditions, explicit success and failure end conditions, and recovery branches. NotGrasped, NotPlugged, NotScrewed, and TargetNotReached are modeled as named outcomes. Sensor faults and collisions are reflected in the stop condition $p$6, timeouts are represented by events such as Timer.exceeded, and impedance parameters $p$7 and $p$8 are set per motion to provide compliant behavior under pose estimation noise and contact variation. Recovery patterns in the examples include reopening the gripper, rotating back, retrying the screw action, re-localizing, re-approaching, or terminating safely (Thomas et al., 2014).

Giskard generalizes monitoring into first-class nodes. A Monitor evaluates predicates over the world model and sensor inputs, updates its Observation FSM with True, False, or ?, and can pause, resume, cancel, or chain subcharts. In the cutting example, “Human Close?” pauses the “Cut” template, while “Made Contact?” and “Done?” guard progression and repetition. Because all taskActive nodes contribute constraints concurrently and switching is coordinated through jerk-bounded lMPC, tasks can be added or removed seamlessly at any control cycle rather than only at phase boundaries (Stelter et al., 12 May 2026).

The rail motion literature develops a more explicitly safety-oriented view of monitoring and guarding. Safety invariants include mutual exclusion between DoorsOpen and Moving, the braking-distance condition

$p$9

segment speed limits, occupancy exclusion, and the approach lock

$(flag, TF, GF, JV, ST, DA)$0

It also recommends hysteresis to avoid state flapping around kinematic thresholds and gives EmergencyBrake higher priority than normal deceleration. These constructs show how motion statecharts can combine discrete interlocking with continuous kinematic criteria (Al-Fedaghi, 2021).

Taken together, the literature treats monitoring not as an auxiliary concern but as a central semantic layer. In one line of work monitors determine recovery and safe termination for manipulation; in another they directly modulate active constraints; in the rail context they enforce interlocking, timing, and braking safety.

6. Representative applications, comparative position, and limitations

LightRocks provides two detailed manipulation exemplars. The screwing skill is built from the Elemental Actions Spinning, SpinningBack, and CloseGripper, with a torque threshold of $(flag, TF, GF, JV, ST, DA)$1 Nm on $(flag, TF, GF, JV, ST, DA)$2, retries through back-rotation of $(flag, TF, GF, JV, ST, DA)$3, and timeout-driven abortion to NotScrewed. The grasping and plugging task on a top hat rail composes the Skills GraspingObject, TransferingToPlugPose, Plug, and Push, with perception updating the environment model, MoveTo using Cartesian impedance, and success or failure transitions such as IsGrasped, TargetReached, Plugged, and Pushed. In the case study “PluggingObjectsOnTopHatRail,” a plan sequences three tasks, each a GraspingAndPlugging Task, and programming the task by reusing predefined skills took less than an hour (Thomas et al., 2014).

Giskard contributes case studies that stress online task switching and embodiment transfer. The cutting example combines a sequential “Cut” template with a parallel safety monitor and exposes semantic annotations over time, including a proximity event visible at $(flag, TF, GF, JV, ST, DA)$4–$(flag, TF, GF, JV, ST, DA)$5s. The peg-in-hole insertion task with dual UR10 robots uses always-active and phase-specific constraints, and frequent switching yields smooth measured joint velocity profiles. The framework was deployed on eight real robots including PR2, TIAGo, HSR, Stretch2, dual UR10, and others; implemented MSC nodes such as Cartesian pose, joint goal, feature functions, door/drawer opening, cutting, differential-drive navigation, peg-in-hole, and five-finger grasp were reused across robots with minimal tuning. Only two lMPC parameters were robot-specific: timestep $(flag, TF, GF, JV, ST, DA)$6 of $(flag, TF, GF, JV, ST, DA)$7–$(flag, TF, GF, JV, ST, DA)$8 s and horizon length $(flag, TF, GF, JV, ST, DA)$9 typically $flag$0–$flag$1, with identical values $flag$2 s and $flag$3 used for fast kinematic simulations (Stelter et al., 12 May 2026).

The railcar system shows how similar principles apply outside manipulation. Event partitions $flag$4–$flag$5 govern entry into segment $flag$6, setting Approaching, early reservation of terminal $flag$7, a 90 s dwell, authorization to depart into $flag$8, and repeated traversal of $flag$9 segments. This example highlights that Motion Statecharts can encode motion behavior for transportation systems as well as robot manipulators, provided continuous movement is translated into discrete events and guarded concurrent regions (Al-Fedaghi, 2021).

In comparative terms, LightRocks narrows UML/P to motion-centric elements and adds domain parameters such as $$Skill := (Nodes^*, Transitions^*, StartNodes^*, StopNodes^*)$$0, $$Skill := (Nodes^*, Transitions^*, StartNodes^*, StopNodes^*)$$1, $$Skill := (Nodes^*, Transitions^*, StartNodes^*, StopNodes^*)$$2, and $$Skill := (Nodes^*, Transitions^*, StartNodes^*, StopNodes^*)$$3, together with stereotypes for state reuse across models. Giskard positions MSCs against typical BT integrations, Stack-of-Tasks, and QP-control approaches by integrating statechart semantics directly into the high-frequency control loop and using a unified differentiable world model of robot and environment. The rail work, by contrast, foregrounds Harel-style hierarchy, orthogonality, event broadcast, and run-to-completion as the basis for safe motion eventization (Thomas et al., 2014, Stelter et al., 12 May 2026, Al-Fedaghi, 2021).

The limitations are also distinct. LightRocks does not use orthogonal regions in the current system, aims for more concurrency on the Statechart level in future work, does not formalize timing and scheduling guarantees beyond timer guards, and requires domain-specific adapters for each robot API. Giskard has no dedicated force control, focuses on execution rather than integration with sampling-based planning or trajectory optimization, depends on world-model fidelity, and does not claim formal safety guarantees beyond kinematic constraint adherence. This suggests that Motion Statecharts are best understood as a powerful execution and coordination formalism whose effectiveness depends on the surrounding control, sensing, and model infrastructure (Thomas et al., 2014, Stelter et al., 12 May 2026).