Inverse Kinematics example is not up-to-date

The Inverse Kinematics example script does not work out-of-the-box, and will error out with a message about control_freq being specified in Fetch’s configuration file.

When this error is bypassed by commenting out the assertion, errors still occur. Fetch does not have a “robot_body” attribute, so

fetch.robot_body.reset_position([0, 0, 0])

should become

fetch.reset_position([0, 0, 0])

which is the standard in the functioning examples.

Similarly, it seems that

fetch.get_end_effector_position()

should become

fetch.links["gripper_link"].get_position()

RobotLink does not have a body_part_index, so

robot_id, fetch.links["gripper_link"].body_part_index, [x, y, z], threshold, maxIter

should become something like

robot_id, fetch.links["gripper_link"].(body/link)_id, [x, y, z], threshold, maxIter

After all of these changes, the example wildly flails around Fetch’s arm, which I wouldn’t imagine is the intended purpose of the example.

This script is fairly important for outlining the usage of IK in iGibson. If I fix it, I will submit a PR. Just wanted to outline the issue here as well.

[CharlesAverill]

@cgokmen IK runs without a hitch now, my team and I appreciate the attention and work y’all put into this repo.

One (unrelated) thing I’m curious about: does iGibson support any sort of motion planning to move an appendage from its current position to another position (computed by IK in my case)? I’m currently working on porting some motion planning code, but it’s proving to be tough, an official solution would be much preferred.

[ChengshuLi]

@CharlesAverill Thank you for reporting this. We are aware that several of our examples are currently broken (including the IK example). We are in the process of fixing them (and making them much better than before!). We will release a new version in a week or two.