Batching and caches
EROBS combines compatible steps and reuses planning resources to reduce repeated work:
Batching combines several script steps into one MTC task.
Model reuse avoids loading the same robot model for each task.
Plan caching lets a later request replay a stored trajectory.
These mechanisms have different lifetimes and matching rules. Batching also changes how previews, pauses, and cancellation behave.
Execution batches
With batching enabled, group_into_batches() groups consecutive moveto and end_effector steps. Any other task ends the current batch and runs as a separate unit. Step order stays unchanged.
Example: MoveTo → End effector → Pause → MoveTo creates three units: the first two steps together, Pause alone, then a one-step MoveTo batch.
The orchestrator builds, plans, and executes each batch as one MTC task. Pause and cancellation requests are handled after the active unit returns. An explicit pause step waits for Resume, but also makes the script ineligible for preview: preview supports only moveto and end_effector.
Batching is enabled by default; enable_batching:=false makes each step a separate unit. Grouping depends on task type, with no special break for ePick operations and no automatic vacuum-seal check between a gripper step and the next movement.
Preview start states
For a robot staying at A during preview, with requested targets B then C:
Batching |
Planned path |
What it checks |
|---|---|---|
Enabled |
A → B → C |
One connected sequence in a single MTC task |
Disabled |
A → B, then A → C |
Each move separately from the live robot state |
An unbatched preview does not carry the previous step’s planned joint or gripper state forward. It therefore does not check the B → C transition that execution would attempt after reaching B. Use batching to preview the connected sequence. The GUI replaces its displayed preview when each new trajectory arrives.
Model and planner reuse
BaseStages keeps the most recently loaded robot model in its own process, identified by a model revision. The revision identifies the tool and its applicable cup profile; relaunching the same configuration retains the same identity. Each MoveIt-using action server receives it with its goal (the pipettor goal has no revision field); batches inside the orchestrator read it from the lifecycle manager.
Planner objects are reused only within one MTC task. Creating the next task clears the planner cache because those objects can retain state from the previous task. See tool and MoveIt lifecycle for model changes.
When a plan can be reused
The orchestrator’s PlanCache holds up to 64 serialized solutions in memory. It evicts the least recently used entry when full; restarting the orchestrator discards the cache.
A goal is eligible only when its entire task list forms one batch. A successful fresh preview or execution can store its solution. A later execution can replay it when all cache-key inputs match:
Input |
Matching rule |
|---|---|
Expanded tasks and resolved poses |
Whitespace and object-key order are normalized; task order and pose values are preserved |
MoveIt model |
Same tool/cup-profile revision |
Starting arm joints, when available |
Six angles in radians, rounded to two decimal places; whole-turn differences remain distinct |
If the lifecycle manager lacks a complete six-joint state, the key has no known starting position. This also occurs with mock hardware, where that manager does not subscribe to joint states. A cache match alone does not establish execution readiness.
Goals containing several units are not eligible. With batching disabled, even a single MoveTo has no trajectory-replay eligibility. Preview always plans afresh; it never replays a cached trajectory.
What does not invalidate a plan
A change to a pose value resolved from the registry changes the key. Unused registry entries and entries overridden by inline poses do not affect it.
The key still excludes the planning scene and the contents of model/calibration files. Moving an obstacle can leave the key unchanged, and relaunching the same tool/cup profile keeps its model identity. Replay does not run a fresh collision-planning pass.
After a scene change, generate and inspect a new preview. A successful eligible preview replaces the matching cache entry; a failed preview leaves an older entry in place. Restart the affected processes after editing model or calibration files so both model and trajectory caches are rebuilt. There is no cache-clear service.
Replay failure handling
The orchestrator submits the stored solution to MoveIt and handles the outcome as follows:
Replay outcome |
Next action |
|---|---|
Success |
Complete the batch |
Error beginning with |
Abort and fault the orchestrator; do not dispatch another trajectory |
Any other returned error |
Plan and execute the whole batch afresh |
The fresh attempt applies to server unavailability, goal rejection, an unsuccessful MoveIt result, and caught execution exceptions. Earlier motion or gripper effects may repeat. Since only single-batch goals are eligible, this can repeat the entire submitted sequence.
If that fresh attempt also fails, the goal aborts. There is no further retry loop. See execution controls for interpreting results and fault recovery.