Skip to content

LIBERO-10 Task 6 can succeed before the chocolate pudding contacts the table #149

Description

@rriakang

Hi, while running evaluation simulations on LIBERO-10, I noticed an unexpected behavior in the following task:

put the white mug on the plate and put the chocolate pudding to the right of the plate

The episode was marked as successful while the chocolate pudding was still slightly above the table. Since this looked unusual, I checked the task's success condition in the code to understand why this was happening.

Observed behavior

After successfully placing the white mug on the plate, the episode can terminate as soon as the chocolate pudding enters the target region to the right of the plate, even before the pudding physically contacts the table.

I attached a simulation video showing this behavior.

The following goal predicate appears to become True while the pudding is still in the air:

task06_ep000_ok_dual.mp4
(On chocolate_pudding_1 living_room_table_plate_right_region)

Reproduction

  1. Run the LIBERO-10 task:

    put the white mug on the plate and put the chocolate pudding to the right of the plate

  2. Place the white mug on the plate.

  3. Move the chocolate pudding toward the target region to the right of the plate.

  4. Keep the pudding slightly above the table while moving its center into the target region.

  5. The task can be marked as successful before the pudding physically contacts the table.

Code path I checked

After observing this behavior, I traced the success predicate through the code.

The task goal is defined in:

libero/libero/bddl_files/libero_10/LIVING_ROOM_SCENE6_put_the_white_mug_on_the_plate_and_put_the_chocolate_pudding_to_the_right_of_the_plate.bddl

as:

(On porcelain_mug_1 plate_1)
(On chocolate_pudding_1 living_room_table_plate_right_region)

The living-room table region is created as a TargetZone in:

libero/libero/envs/problems/libero_living_room_tabletop_manipulation.py

TargetZone is defined in:

libero/libero/envs/objects/target_zones.py

From what I understand, the living room table is not assigned as the parent_name of this TargetZone.

The relevant check_ontop() logic is implemented in:

libero/libero/envs/object_states/base_object_states.py

and effectively behaves as follows:

if parent_object is None:
    return this_object.under(...)
else:
    return this_object.under(...) and self.env.check_contact(
        parent_object, other_object
    )

Therefore, when the TargetZone has no parent object, the physical contact check appears to be skipped.

The spatial condition itself is implemented in:

libero/libero/envs/objects/site_object.py

where under() checks whether the object's center is inside the target region in the XY plane and within the allowed vertical range.

The default vertical tolerance extends up to approximately 0.10 m above the region.

This seems to explain the behavior observed in the simulation: the pudding can satisfy the On predicate while it is still above the table, as long as its position falls within the target region and the allowed height range.

Question

Is this behavior intentional for TargetZone regions?

I understand that the instruction "to the right of the plate" describes a spatial relation, so it may be intentional that physical contact with the table is not required.

However, I wanted to confirm whether it is expected for the episode to terminate successfully while the pudding is still in the air.

Activity

  1. sattyamjjain commented on Sep 7, 2026

    @sattyamjjain

    Confirming this from a different direction. I run adversarial evaluations on this suite, and a false-positive success predicate hits me twice: it inflates the clean baseline, and it deflates every attack number measured against it, so the harm compounds rather than cancelling.

    Reproduced on LIBERO-10 task 6. The success check fires on the release condition rather than on contact, so a drop from height counts.

    The narrowest fix that does not change any other task is to add a contact condition to the predicate for this task only, rather than touching the shared success logic. I can open a PR with that plus a regression case if you want it, but it changes published numbers for anyone who has benchmarked on task 6, so I would rather you decide the shape before I write it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions