Anatomy of a named-move task
The complete named-move example has start_gripper none, an inline example_home pose containing six joint angles in degrees, and one moveto task whose target is example_home. Inline pose data takes priority; the parser fills missing names from the registry. If a MoveTo name remains absent, its motion stage tries an SRDF named state. These are illustrative parser inputs, not a validated robot motion.
EROBS / TASK ANATOMY
Anatomy of a named-move task
One document declares the starting tool, named poses, and ordered work.
named-move.json
{
"start_gripper": "none",
"poses": {
"example_home":
[0, -90, 90, -90, -90, 0]
},
"tasks": [
{
"task_type": "moveto",
"target":
"example_home"
}
]
}
The same pose name connects the task to its joint values.
Starting tool model
A key in the beamline’s grippers.
Declares the already attached tool.
Inline pose values
Six joint angles, in degrees.
This example supplies its own pose.
Ordered task list
One MoveTo step in this example.
target is a name, not XYZ.
The list must be nonempty.
How a named target is resolved
1 Inline pose
Use the document’s value.
example_home resolves here.
2 Pose registry
Fill names absent from poses.
Inline values keep priority.
3 SRDF state
If still absent, MoveTo tries
the robot model’s named state.
Illustrative parser input. Parsing does not establish reachability or collision clearance.