Skip to main content
Pre-release

This release is a pre-release and may not be stable for production use.

Pinker

Build Documentation

Python inverse kinematics for embedded robots.

Pinker is a leaner version of Pink for single-board computers. Two dependencies, one C file, and it takes 5 seconds to build from source on a Raspberry Pi 4. But it doesn't implement collision avoidance.

Installation

You can install the library from PyPI:

pip install pinker

You can also clone the repository and run it locally:

git clone https://github.com/pink-kinematics/pinker.git && cd pinker
uv run examples/g1_com_tracking.py

Usage

Pinker solves differential inverse kinematics by weighted tasks. A task is defined by a residual function $e(q)$ of the robot configuration $q \in \mathcal{C}$ to be driven to zero. For instance, putting a foot position $p_{foot}(q)$ at a given target $p_{foot}^{\star}$ can be described by the position residual:

$$ e(q) = p_{foot}^{\star} - p_{foot}(q) $$

In differential inverse kinematics, we compute a velocity $v \in \mathfrak{c}$ that satisfies the first-order differential equation:

$$ J_e(q) v = \dot{e}(q) = -\alpha e(q) $$

where $J_e(q) := \frac{\partial e}{\partial q}$ is the task Jacobian. We can define multiple tasks, but some of them will come into conflict if they can't be all fully achieved at the same time. Conflicts are resolved by casting all objectives to a common unit, and weighing these normalized objectives relative to each other. We also include configuration and velocity limits, making our overall optimization problem a quadratic program:

$$ \begin{align} \underset{v \in \mathfrak{c}}{\text{minimize}} \ & \sum_{\text{task } e} \Vert J_e(q) v + \alpha e(q) \Vert^2_{W_e} \ \text{subject to} \ & v_{\text{min}}(q) \leq v \leq v_{\text{max}}(q) \end{align} $$

Pinker provides an API to describe the problem as tasks with targets, and automatically build and solve the underlying quadratic program.

Task costs

Here is the example of a biped robot that controls the position and orientation of its base, left and right contact frames. A fourth "posture" task, giving a preferred angle for each joint, is added for regularization:

from pinker.tasks import FrameTask, PostureTask

tasks = {
    "base": FrameTask(
        "base",
        position_cost=1.0,              # [cost] / [m]
        orientation_cost=1.0,           # [cost] / [rad]
    ),
    "left_contact": FrameTask(
        "left_contact",
        position_cost=[0.1, 0.0, 0.1],  # [cost] / [m]
        orientation_cost=0.0,           # [cost] / [rad]
    ),
    "right_contact": FrameTask(
        "right_contact",
        position_cost=[0.1, 0.0, 0.1],  # [cost] / [m]
        orientation_cost=0.0,           # [cost] / [rad]
    ),
    "posture": PostureTask(
        cost=1e-3,                      # [cost] / [rad]
    ),
}

Orientation (similarly position) costs can be scalars or 3D vectors. They specify how much each radian of angular error "costs" in the overall normalized objective. When using 3D vectors, components are weighted anisotropically along each axis of the body frame.

Task targets

Aside from their costs, most tasks take a second set of parameters called target. For example, a frame task aims for a target transform, while a posture task aims for a target configuration vector. Targets are set by the set_target function:

    tasks["posture"].set_target(
        [1.0, 0.0, 0.0, 0.0] +           # floating base quaternion
        [0.0, 0.0, 0.0] +                # floating base position
        [0.0, 0.2, 0.0, 0.0, -0.2, 0.0]  # joint angles
    )

Body tasks can be initialized, for example, from the robot's neutral configuration:

from pinker import Configuration, load_robot_description, solve_ik

robot = load_robot_description("ur3_official_description")
configuration = Configuration(robot.model, robot.data, robot.q0)
for body, task in tasks.items():
    if type(task) is FrameTask:
        task.set_target(configuration.get_transform_frame_to_world(body))

A task can be added to the inverse kinematics once both its cost and target (if applicable) are defined.

Differential inverse kinematics

Pinker solves differential inverse kinematics, meaning it outputs a velocity that steers the robot towards achieving all tasks at best. If we keep integrating that velocity, and task targets don't change over time, we will converge to a stationary configuration:

dt = 6e-3  # [s]
for t in np.arange(0.0, 42.0, dt):
    velocity = solve_ik(configuration, tasks.values(), dt, solver="quadprog")
    configuration.integrate_inplace(velocity, dt)
    time.sleep(dt)

If task targets are continuously updated, there will be no stationary solution to converge to, but the model will keep on tracking each target at best. By default, solve_ik will take into account both joint limits and velocity limits read from the robot model.

Compatibility

Pinker is API-compatible with Pink 4.4.0, with the following exceptions:

  • Default limits live on the configuration, as configuration.default_limits, rather than being cached on the robot model. Add your own, for instance a FloatingBaseVelocityLimit, by appending to that list.
  • Configuration.integrate returns a new Configuration rather than a configuration vector. Its vector is configuration.integrate(v, dt).q.
  • Functions and methods of the kinematics backend follow Python naming, so model.getFrameId is model.get_frame_id and model.lowerPositionLimit is model.lower_position_limit. Model getters raise rather than returning the sentinel index Pinocchio returns when a name is not found.

Pinker is a standalone replacement for Pink where kinematics are carried out by pinker.kinematics, a backend written as a single C extension with a thin Python layer. Tasks, limits, barriers, the Configuration class and solve_ik, is the same as in Pink, and differential IK problems are still solved through qpsolvers.

Examples

The examples/ directory mirrors Pink's examples, ported to the pinker.kinematics backend with Viser visualization. Each one is named <robot>_<task>.py, after the robot description it loads and what it does with it:

pixi run -e examples python examples/ur3_end_effector_tracking.py

Each example can also be run standalone with uv:

uv run examples/ur3_end_effector_tracking.py

Check out the examples directory for more.

Limitations

  • No collision support: Pink's SelfCollisionBarrier is not available, and neither Configuration nor RobotWrapper carries a collision model or collision data. Use Pink if you need collision-avoidance tasks.
  • One visualizer: Pinker works with Viser, which handles both visualization and user inputs. If you would rather use (the older) MeshCat, head over to Pink, which is compatible with it.
  • The pinker.kinematics backend is not type-checked yet: mypy is disabled on it in pyproject.toml. Enabling it is a matter of shipping a _kinematics_c.pyi stub for the C extension, annotating the arrays cached in Model._packed and the optional values the URDF parser reads, then removing the override.

Benchmark

Pinker and Pink can be compared using pinker_benchmark, a standalone pixi project that runs a collection of arm and humanoid examples. On a Raspberry Pi 4 Model B:

TODO: benchmark results

See the readme and data files in the benchmark repository for more details.

Citation

If you use Pinker in your scientific works, please cite it e.g. as follows:

@software{pinker,
  title = {{Pinker: Python inverse kinematics for embedded robots}},
  author = {Caron, Stéphane and De Mont-Marin, Yann and Budhiraja, Rohan and Bang, Seung Hyeon and Domrachev, Ivan and Nedelchev, Simeon and Du, Peter and Escande, Adrien and Vaillant, Joris and Wingo, Bruce and Patapati, Santosh and San José Pro, Daniel and Marticorena Vidal, Nicolas Guillermo},
  license = {Apache-2.0},
  url = {https://github.com/pink-kinematics/pinker},
  version = {0.1.0},
  year = {2026}
}

Don't forget to add yourself to the BibTeX above and to CITATION.cff if you contribute to this repository.

See also

Software:

  • Jink.jl: Julia package for differential multi-task inverse kinematics.
  • mink: differential inverse kinematics in Python, based on the MuJoCo physics engine.
  • Pink: precursor to Pinker based on Pinocchio.
  • Pinocchio: C++ rigid body dynamics algorithms library and reference implementation for the C kinematics backend of Pinker.
  • PlaCo: C++ differential multi-task inverse kinematics based on Pinocchio.
  • pymanoid: precursor to Pink and Pinker based on OpenRAVE.
  • TSID: C++ inverse kinematics based on Pinocchio.

Technical notes:

Metadata

Release files for pinker 0.1.0a0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for pinker 0.1.0a0
File Size Uploaded
pinker-0.1.0a0.tar.gz 102.7 kB Details

Release files / pinker-0.1.0a0.tar.gz

Download URL pinker-0.1.0a0.tar.gz
Size 102.7 kB
Tags Source
SHA-256 checksum
How to use checksums
8e59296dedc7f7081ea979b6d34a44fcfc35c2f008f05cdf23f6a31d3967ba77
BLAKE2b-256 checksum
How to use checksums
c797e390be2e703611ea4fc0cbab755aa31fd81799ce83914c93bca4306fd534
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.12.13

Release history Release notifications | RSS feed

1.0.0

1 release file

0.1.0

1 release file

This release

0.1.0a0 This release

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page