Update pin to latest

[lucasjinreal]

Hi, pin uses 3.8 now, but placo install only use 3.4
too many APIs changed and new features changed from 3.4 to 3.8, suggest keep that to date.

[Gregwar]

Hello,

Just released v0.9.17:
https://github.com/Rhoban/placo/releases/tag/v0.9.17

The dependency to pin is upgraded to 3.8.0. (this was already the case on the master branch which was not released yet)
This also implies the drop of python3.8 and the support of python3.14

Let us know if everything work for you

[lucasjinreal]

hi，does it uploaded to pypi

[Gregwar]

Yes it is

[lucasjinreal]

hi, may i consult one last question, does placo more easier than pink? I tried pink even though it consist of self-body limit constraint, but speed relatively slower than pinocchio itself.

am current using pink like below:

def compute_joint_angles(
        self,
        end_effector_position,
        end_effector_orientation=None,
        initial_joint_positions=None,
        trim_base_link=False,
        max_iter=530,
        dt=1e-2,
        fixed_joint_indices=[0],
    ):
        # q = self._ensure_start_joint_pos_right(initial_joint_positions)
        q = (self.model.lowerPositionLimit + self.model.upperPositionLimit) / 2.0

        pos = np.array(end_effector_position, dtype=float)
        if end_effector_orientation is None:
            orientation_matrix = np.eye(3)
        else:
            if len(end_effector_orientation) == 3:
                orientation_matrix = R.from_euler(
                    "xyz", end_effector_orientation
                ).as_matrix()
            elif len(end_effector_orientation) == 4:
                orientation_matrix = R.from_quat(end_effector_orientation).as_matrix()
            else:
                raise ValueError(
                    "end_effector_orientation must be length 3 (euler) or 4 (quat)"
                )

        oMdes = pin.SE3(orientation_matrix, pos)

        eps = 1e-4
        damp = 1e-7

        tasks = [
            FrameTask(
                self.end_link_frame_name, position_cost=1.0, orientation_cost=1.0
            ),
        ]

        try:
            tasks[0].set_target(oMdes)
        except Exception as e:
            import traceback

            traceback.print_exc()
            pass

        i = 0

        success = False
        for i in range(max_iter):
            configuration = Configuration(
                self.model,
                self.data,
                q,
            )

            velocity = pink.solve_ik(
                configuration,
                tasks,
                dt=dt,
                damping=damp,
                # solver="osqp",
                solver="quadprog",
                # safety_break=False
            )

            q = configuration.integrate(velocity, dt)

            iMd = configuration.data.oMf[self.end_link_id].actInv(oMdes)
            err = pin.log(iMd).vector

            if np.linalg.norm(err) < eps:
                logger.success("Convergence achieved!")
                success = True
                break

            if not i % 80:
                print(f"{i}: err = {[round(x, 6) for x in err.tolist()]}")

        if not success:
            logger.warning(
                "\n"
                "Warning: the iterative algorithm has not reached convergence "
                "to the desired precision"
            )
        return q

Am wondering how could use placo to achive simillar result but faster

[Gregwar]

Hello, and sorry for the lag

Pink is written in pure Python, while PlaCo is written in C++ with Python bindings. This makes it harder to package and sometime to install, but some code executed by PlaCo (like problem construction) can maybe run faster. Mostly, it is mostly interesting if you consider using PlaCo as a C++ library instead of Python library for embedded application, which is also possible with a relatively similar API.

My intuition is that you would maybe not feel a big difference on typical computers, but maybe it could be different on embedded (e.g Raspberry Pi) systems, where Python interpreter becomes very costly to run

About your use case, can you provide the robot URDF and the goal you are trying to reach ?

Do not hesitate to get inspired by the examples gallery if you want a starting point
https://placo.readthedocs.io/en/latest/kinematics/examples_gallery.html

[Gregwar]

Some remarks/questions:

• You appear to have only a target effector frame, how many joints do you operate ?
• What is your current benchmark, and what is your target computation time for your application ?
• Your function is using cold start, meaning that you always start with (q_min+q_max)/2. If you are following a trajectory, it would be much more efficient to keep your configuration and warm start every time. This is because the underlying methods are iterative, a good initial guess will significantly reduce computation