Motivation
The tsr library has a TSRChain class that couples multiple TSRs across different links of the kinematic chain. pycbirrt currently only accepts list[TSR], all of which constrain the end-effector. There is no reason the planner shouldn't support the full CBiRRT paper formulation.
Canonical use cases:
- Constrained transport: end-effector must hold a mug upright (EE TSR) while avoiding a shelf region (elbow TSR)
- Door opening: gripper at door handle TSR, elbow at hinge-clearance TSR, both enforced simultaneously
- Bimanual: two end-effectors each with their own TSR, projected together
What needs to change
1. RobotModel interface
Add FK for arbitrary links, not just the end-effector:
def fk_link(self, q: np.ndarray, link_name: str) -> np.ndarray: ...
2. IKSolver interface
Add support for solving IK under multiple simultaneous TSR constraints (one per link). The current solve / solve_valid only targets the EE.
3. _project_to_constraint in planner.py
Currently projects onto the worst-violating single TSR. For chains:
- Compute FK for each constrained link
- Accumulate violations across all TSRs in the chain
- Project using a Jacobian that maps all constrained links jointly
4. Planning API
Accept TSRChain (or list[TSRChain]) alongside list[TSR]:
planner.plan(
goal_tsrs: list[TSR | TSRChain] | None = None,
constraint_tsrs: list[TSR | TSRChain] | None = None,
...
)
A bare TSR is a degenerate chain of length 1 (EE only) — backward compatible.
Complexity note
The main difficulty is the IK solver: solving IK under multi-link TSR constraints requires either:
- A constrained IK formulation (e.g., nullspace projection)
- Iterative projection using per-link Jacobians
The MuJoCo backend currently uses a simple EE IK. This will need extension or a fallback to numerical projection.
Acceptance criteria
Motivation
The
tsrlibrary has aTSRChainclass that couples multiple TSRs across different links of the kinematic chain. pycbirrt currently only acceptslist[TSR], all of which constrain the end-effector. There is no reason the planner shouldn't support the full CBiRRT paper formulation.Canonical use cases:
What needs to change
1.
RobotModelinterfaceAdd FK for arbitrary links, not just the end-effector:
2.
IKSolverinterfaceAdd support for solving IK under multiple simultaneous TSR constraints (one per link). The current
solve/solve_validonly targets the EE.3.
_project_to_constraintinplanner.pyCurrently projects onto the worst-violating single TSR. For chains:
4. Planning API
Accept
TSRChain(orlist[TSRChain]) alongsidelist[TSR]:A bare
TSRis a degenerate chain of length 1 (EE only) — backward compatible.Complexity note
The main difficulty is the IK solver: solving IK under multi-link TSR constraints requires either:
The MuJoCo backend currently uses a simple EE IK. This will need extension or a fallback to numerical projection.
Acceptance criteria
RobotModelprotocol exposesfk_link(q, link_name) -> np.ndarray_project_to_constrainthandlesTSRChainby projecting all links jointlyplan()acceptsTSRChainingoal_tsrsandconstraint_tsrs