Argument missing in calculateInverseKinematics() function regarding calculation in local frame

[lok-i]

Hi,

I am currently working with my quadruped robot in pybullet and require my IK function to be in the local frame as the robot is mobile(unlike manipulators). However, the calculateInverseKinematics(), requires the target positions in the world frame, which is impractical to generate.

I went through your MPC implementations for Laikago, a1, etc and found that u transformed the coordinates from world to body frame but the documentation talks about a parameter named "currentPosition" which upon initialized by the user will enable the calculateInverseKinematics() to do the calculations in the local frame of the robot. However, this argument is missing in the code and It would be straight forward and easy to implement if this issue is resolved.

[lok-i]

any updates on this issue, @erwincoumans ?

[silverjoda]

As in several functions in pybullet that I've noticed, their single_input version doesn't work properly or doesn't accept a certain argument. What you can do instead is use calculateInverseKinematics2 and put in all 4 of your leg tips, which is preferable anyway because it's faster. It works for me for my hexapod. I can't figure out what the 'currentPosition' is so I just set it to all zeros and it works.

[erwincoumans]

Indeed, silverjoda, calculateInverseKinematics2 is recommended. Fixing existing APIs breaks user scripts. To avoid that, I added the new API, v2. For currentPosition, you can provide the current joint positions, often they are close to the solution.

[silverjoda]

Hi, Erwin. I initially used the current joint positions for the currentPosition but it ended up doing something different to what I expected so I stuck with using zeros.
I tried it just now on on a trained policy and it looks like it works when using current joint angles as well, so perhaps I was doing
something wrong initially.
Thanks

EDIT: Nope, it completely screws up the policy when I use the current joint angles as the currentPosition

hex_phases.mp4

[silverjoda]

hex_phases_fail.mp4

If I use joint angles as currentPosition then this happens :)

[lok-i]

Indeed, silverjoda, calculateInverseKinematics2 is recommended. Fixing existing APIs breaks user scripts. To avoid that, I added the new API, v2. For currentPosition, you can provide the current joint positions, often they are close to the solution.

So @erwincoumans , when you initialize does the calculateInverseKinematics2(), operate in the local body(base) frame of the robot (i.e should the end effector target positions be given with respect to the base of the robot?). Something of similar meaning is given in the docs and also calculating inverse kinematics with the targets in the world co ordinates is not very flexible at times.

[silverjoda]

As it says in the documentation, it's given in world coordinates, unless you specify this "currentPosition" argument, which makes it in the local body frame. I can confirm that this is true.