A 10 mm position delta does not identify its own starting point. Applied to a reported x position of 3 mm, it gives a 13 mm target. Applied to a previous goal of 20 mm, it gives a 30 mm target. Both calculations use the same delta; they differ in the state used as its reference.
That distinction becomes visible when a position report repeats. An actual Blender geometry experiment compares four prescribed reports with achieved-relative, desired-relative and fixed absolute targets. Independent calculations agree with the measured target coordinates. This is a study of reference-state arithmetic, not a robosuite controller rollout or a measurement of a robot failing to reach a goal.
The reference state changes the next target
Take four supplied x positions of 0, 3, 3 and 16 mm. Keep y=6 mm and z=4 mm throughout. On each update, supply the same position delta: +10 mm along x, with no y or z increment. These increments are already in physical length units; they are not normalized policy actions.
For achieved-relative updates, add the delta to each supplied position. The resulting x targets are 10, 13, 13 and 26 mm. The two identical 3 mm reports produce identical 13 mm targets. This rule does not remember the preceding desired target when choosing its position reference.
For desired-relative updates, initialize the previous goal to the first report, then add the delta to the previous goal at every update. The x targets are 10, 20, 30 and 40 mm. The repeated report does not stop the target from advancing, because this recurrence reads the stored goal instead of that report.
An absolute action answers a third question: where should the position target be? In this example the supplied absolute target is always (40, 6, 4) mm. Reusing it does not accumulate another 40 mm each time. The absolute target and the last desired-relative target happen to coincide here because of our chosen inputs, not because the two action conventions are generally equivalent.
None of these alternatives is automatically the correct one for a task. Desired-relative commands preserve the specified sequence of goal increments even when supplied reports differ from those goals. Achieved-relative commands keep each new target tied to the supplied position. Neither arithmetic rule establishes how a physical robot will move, whether it will track the target, or whether the target is safe.
Inspect the position helper, not only the action label
The inspected robosuite OSC source is pinned to commit 5ce6643f3092639d08f7b0f90ed1c6a84f50552c. Its set_goal delta branch scales the action before passing the position component to compute_goal_pos. That helper can use the current reference position in achieved mode or the stored goal in desired mode. The absolute branch assigns the position target directly. These statements describe this position path, not every robosuite controller.
The same file’s reset_goal initializes the goal from current state and has an achieved-mode default. That method default does not establish that the constructor itself initializes the internal mode. Also, the inspected position helper raises NotImplementedError when position_limits is supplied; this code does not justify promising target clipping.
The captured live controller documentation uses control_delta wording, while this pinned source exposes input_type, input_ref_frame and separate goal-update state. Treat documentation and code as versioned interfaces. Before transferring an action recipe, inspect the exact controller file, scaling path, coordinate frame, mode setter and reset used by your application; do not assume similarly named options are interchangeable.
A small recurrence you can inspect
The code below performs only the illustrative position arithmetic in one frame. It does not import robosuite or read an actual robot state. Update index is a sequence label: there is no assigned elapsed time, controller frequency or velocity estimate.
# Prescribed positions, already in metres; no controller or motion execution.
reports = [(0, .006, .004), (.003, .006, .004),
(.003, .006, .004), (.016, .006, .004)]
delta = (.010, 0, 0)
absolute = (.040, .006, .004)
previous_goal = reports[0]
def plus(a, b):
return tuple(x + y for x, y in zip(a, b))
print("update | report x | achieved-relative x | desired-relative x | absolute x (mm)")
for update, report in enumerate(reports):
achieved_target = plus(report, delta)
desired_target = plus(previous_goal, delta)
print(f"{update:6d} | {1000 * report[0]:8.1f} | "
f"{1000 * achieved_target[0]:19.1f} | "
f"{1000 * desired_target[0]:18.1f} | {1000 * absolute[0]:10.1f}")
previous_goal = desired_target
We ran this AI-operated numerical experiment in Blender 5.2.2 LTS on 6 October 2026. Finite marker corners supplied the position reports and delta. A translation matrix applied that measured delta to the chosen reference; its returned point defined the next target marker. Each desired-relative update read the previously created target marker’s evaluated center. An independent scalar calculation checked the saved coordinates, reference operands and returned targets.
All markers shared one translated, rotated three-dimensional frame. The figure and table convert their measured coordinates back to that local frame. Input-coordinate checks used a fixed 4 µm component allowance; target and inverse-frame comparisons used 80 µm. The largest measured inverse-coordinate discrepancy was about 0.023 µm. These are numerical checks on this construction, not robot accuracy specifications. The absolute target was a separate input marker. No motion, controller or torque calculation was executed.
Measured x coordinates, rounded to 0.1 mm:
| Update index | Supplied report (mm) | From achieved (mm) | From desired (mm) | Fixed absolute (mm) |
|---|---|---|---|---|
| 0 | 0.0 | 10.0 | 10.0 | 40.0 |
| 1 | 3.0 | 13.0 | 20.0 | 40.0 |
| 2 | 3.0 | 13.0 | 30.0 | 40.0 |
| 3 | 16.0 | 26.0 | 40.0 | 40.0 |
Keep the report and the goal distinct in your records
The HoMeR action-convention guide discusses choosing conventions by task phase. That decision still requires specifying which state a relative position command uses. The robot action-data guide explains the broader episode record; add the reference state when those records must explain an individual target update.
When investigating an unexpected next target, record the input action with its units, the position supplied on that call, the stored goal before the update, the active goal-update mode and any reset. A record containing only the delta and final target may conceal which reference was used. Mixing normalized action values with metre deltas introduces a separate error that this example deliberately avoids.
The repeated 3 mm report here is an assigned input, not evidence of stale telemetry or physical tracking lag. Likewise, no result covers orientation actions, interpolation, workspace limits, contact, robot dynamics or controller performance. The useful comparison is narrower: holding the delta fixed while changing its per-call reference state produces a different target sequence, even before any controller tries to reach it.