feat(task): Add ManipulabilityTask for maximizing robot manipulability

[danielsanjosepro]

Summary

This PR adds a new ManipulabilityTask that maximizes the manipulability of a robot manipulator. Higher manipulability means the robot can "move more easily" in all directions, avoiding singular configurations.
This add a controller similar to the MMC of Jesse Haviland and Peter Corke [1]: https://jhavl.github.io/mmc/
The task minimizes:

$$| \dot{m} - \dot{m}_\text{desired} | ^2 = | J_m \dot{q} - \dot{m}_\text{desired} | ^2$$

...where $J_m$ is the manipulability jacobian and $\dot{m}_\text{desired}$ is the desired change of manipulability rate (larger values make the controller more agressive).

This definition diverges from Haviland's [1] but follows a more pink-like standard.

What is included:

New task:

• ManipulabilityTask: A new task that computes and maximizes the manipulability measure.
• Support for configurable Jacobian masks ("position", "orientation", or custom.)

New examples:

1. Planar 2-DOF (planar_2dof_manipulability.py): A simple planar robot arm with interactive Viser sliders to tune manipulability rate and damping in real-time.

2026-02-24.15-37-13.mp4

2. Panda comparison (arm_panda_manipulability_comparison.py): Side-by-side comparison of two Panda arms tracking the same target - one with ManipulabilityTask (full opacity) and one without (gray, 50% opacity).

2026-02-24.15-42-35.mp4

Limitations:

• Not suited for 1kHz control: the hessian is computed in python since the pinocchio bindings for it are currently not available. The solver with the task takes around 1-2 ms, with medium variance. The timing is plotted in the example. Probably the implementation of PlaCo [2] is faster.
• Local IK limitation: The task is still "local" only. Therefore, depending on the previous configurations, it might not lead to a configuration with good manipulability (in the long term). It is interesting to play around with the Panda example and see that you can end up in worse configurations depending on how you move the robot. Probably using a planner (RRT) with manipulability cost will lead to better results...

References / Related Work

[1] Behavior similar to the MMC controller (Manipulability Motion Control) by Haviland and Corke
[2] Similar to PlaCo's manipulability regularization

[stephane-caron]

Thank you @danielsanjosepro for this PR. The manipulability task looks like a great addition, and examples and video are particularly helpful 👍

This message to let you know that reviewing this PR is on my radar. I'll wrap up a release for v4.1.0 with your previous additions, then we can include the new task in a release of its own, like v4.2.0.

[stephane-caron]

This PR is in an excellent state 🤩 I only have one suggestion regarding documenting and checking the revolute-joint assumption in the task constructor. Other review comments are minor nits.

[danielsanjosepro]

I added the revolute joint test (and a test for it) and went through the other comments thanks for the extensive review :)

[stephane-caron]

LGTM. Thank you for this high-quality contribution to the library 👍