PokeRRT: Poking as a Skill and Failure Recovery Tactic for Planar Non-Prehensile Manipulation

TL;DR

This paper tackles the limitations of grasping and pushing for planar object manipulation by introducing poking as a fast, impulsive non-prehensile primitive. It presents two closed-loop kinodynamic planners, PokeRRT and PokeRRT*, that plan in the object configuration space $\mathcal{C}$ using a simulation-based forward model to handle dynamic contact and replanning under uncertainty. The authors formalize poking as a two-phase process with a contact point $p_c$ and impulse magnitude $||\vec{v}_{EE}||$, and demonstrate superior success rates and shorter task times relative to baselines across six scenarios in both simulation and real-world experiments. The work broadens the robotic manipulation toolkit by enabling larger reachable workspaces, faster planning, and robust failure-recovery, with practical implications for industrial and logistics settings.

Abstract

In this work, we introduce PokeRRT, a novel motion planning algorithm that demonstrates poking as an effective non-prehensile manipulation skill to enable fast manipulation of objects and increase the size of a robot's reachable workspace. We showcase poking as a failure recovery tactic used synergistically with pick-and-place for resiliency in cases where pick-and-place initially fails or is unachievable. Our experiments demonstrate the efficiency of the proposed framework in planning object trajectories using poking manipulation in uncluttered and cluttered environments. In addition to quantitatively and qualitatively demonstrating the adaptability of PokeRRT to different scenarios in both simulation and real-world settings, our results show the advantages of poking over pushing and grasping in terms of success rate and task time.

Figures (5)

• Figure 1: This work demonstrates poking as a skill and a failure recovery tactic to increase the portfolio of capabilities at the robot's disposal. Here, an object (blue) is located in an obstacle-rich (red) workspace with non-overlapping reachable regions for each robot defined by beige and green shading. The first robot manipulates the object into the green region successfully via poking (path shown in green), but fails to do so via pushing or grasping (paths shown in orange and purple, respectively).
• Figure 2: Path planning for poking consists of 2 steps: action sampling (a, b) and graph expansion (c, d). (a) Points are sampled uniformly on the object contour (red) and filtered through a conical region originating from the target position (green). Striking points are generated by extending away from contour points in the normal direction. (b) End-effector velocity magnitudes are sampled for each striking point and filtered out if joint velocities are infeasible due to mechanical limitations of the robot. (c) Feasible actions are applied in simulation to get resultant poses. (d) The resultant pose closest to the target position is added to the planning graph.
• Figure 3: The robot successfully pokes the object (blue) from its reachable workspace (orange) to the goal region (green) in all scenarios while avoiding obstacles (red). PokeRRT, PokeRRT*, and baseline algorithms are evaluated in 6 scenarios---no obstacles (S1), $2$ obstacles (S2), $4$ obstacles (S3), wide object (S4), tunnel (S5), and non-overlapping shared workspace (S6). The robot is unable to i) push or pick-and-place in S6 due to limited robot reach, ii) push in S5 due to workspace obstruction in the action path, and iii) pick-and-place in S4 due to object being wider than gripper width.
• Figure 4: Two robots with non-overlapping reachable regions are shown (S6). Robot A (left) applies 2 pokes to manipulate the object to Robot B's (right) workspace (a-d). Robot B then grasps the object and places it in a bin that is not reachable by Robot A (e-f).
• Figure 5: A breakdown of task time as the sum of initial planning, replanning, and execution times is presented for various planners in the real-world. A single bar indicates total task time. Long red bars indicate cases where tasks cannot be solved. Overall, poke planning demonstrates lower execution and replanning times than push planning.