Questions on Tool Definition (Push Action) and Stacking Stability for >2 Blocks

[LeslieLinXinxiang]

Hi!

Thank you for your great work.

I'm currently working on replicating some of the core ideas from your 2018 RSS paper (18-RSS-PhysicalManipulation) using the modern ry Python bindings, and I've encountered two challenging issues that I haven't been able to solve after extensive debugging. I would be very grateful for any guidance!

Issue 1: Defining and Using a "Tool" for a push action

My goal is to have a robot pick up a hook (stick) and use it to push another object (objR).
Observation:

When I define a push rule in my .fol file, the LGP solver does not seem to consider using the tool. Instead, it appears to get stuck in an infinite planning loop exploring other options, eventually consuming all available memory (32GB) and forcing the process to be killed. The plan never includes the (pick stick ...) action.

Question: What is the canonical way in the modern ry library to define a pusher tool and its corresponding push rule in FOL to correctly guide the LGP solver to use it? I suspect I am missing a key concept or predicate.

Here is my definition of the hook in the .g file:

# Hook Definition stick (table_base){ shape:ssBox size:[.8 .025 .04 .01] color:[.6 .3 0] contact, logical:{ object, pusher }, # I assume 'pusher' is the correct logical tag Q: "t(-0.2 0.3 0.02) d(90 0 0 1)", joint:rigid }

stickTip (stick) { Q: "t(.4 .1 0) d(90 0 0 1)", shape:ssBox size:[.2 .026 .04 0.01] color:[.6 .3 0], logical:{ object, pusher }, contact }

Issue 2: Stacking crashes when placing the 3rd block

My second goal is to stack multiple cubes. This works perfectly for stacking 2 blocks, but consistently crashes when attempting to stack the 3rd block.

Observation:
The plan to place the 2nd block on the 1st (e.g., (place objG on objW)) is found and executed successfully. However, the solver crashes when trying to find a plan for the next step, which involves placing the 3rd block on the 2nd (e.g., (place objB on objG)).
The terminal crashes with the following error, and I have attached a screenshot for clarity.

Question: The crash seems to indicate a kinematic loop issue specifically when the target of a place action (To) is another movable object that is not static on the table. Is there a known issue with the stableOn skeleton in this scenario, or is there a different, preferred rule/skeleton for stacking on non-static objects?

Here is the definition for the cubes in the .g file:
All cubes share this structure, with different names and colors.

# Example Cube Definition objG (table) { Q:[-.3, .3, .08], joint:rigid, shape:ssBox, size:[0.06, 0.06, .06, .002], color:[0, 1, 0], contact:1, mass: 0.1, logical:{ is_object, is_place } # I've defined blocks as placeable surfaces }

I'm happy to provide any further information or minimal working examples if needed.