FollowTarget example - calculation cost increases when target position is out of workspace

[PARKBONG]

Hello, I’m trying to apply follow target examples to shadowhand.

IK was solved by applying the RMPflow descriptor only for the index finger, and it seems to work well. However, the problem is that when the target position goes out of the workspace, the FPS drops rapidly.

"standalone_examples/api/omni.isaac.franka/follow_target_with_rmpflow.py " always keeps above 140 fps, but my hand example shows 30~90 fps.

One thing I suspect is that Hand’s structure is more complex than Franka’s.

Currently, I wrote a descriptor only for the index finger. That is, only the leftmost tree in the figure is solved the ik.

robot_descriptor_rh_fftip.yaml

api_version: 1.0
cspace:
    - rh_FFJ4
    - rh_FFJ3
    - rh_FFJ2
    - rh_FFJ1
root_link: world

default_q: [
    0.00, 0.00, 0.00, 0.00
]
cspace_to_urdf_rules: []
composite_task_spaces: []

Q1. Is there a way to ensure that my example always maintains the best fps?
Q2. Is there any example that uses hand robot?

thanks!

[PARKBONG]

Is it good options to change some parameters on LulaKinematicsSolver?

for example, “set_max_iterations()” or “set_default_cspace_seeds()”, etc…

[arudich]

@PARKBONG Sorry for a delayed reply. Yes, the easiest solution would be to change the max_iterations and descent_termination_delta parameters. Inverse Kinematics is not able to easily determine that a target position is outside the workspace of the robot, and so it runs for max iterations before giving up. So playing with these number may help your use-case. But you can also add your own layer of processing to make a bigger impact on the performance.

For instance, you since the finger is moving in an arc, it is probably simple for you to check whether a target position is going to be outside the workspace and simply clip the target position to be within the workspace. Or you could have two instances of IK where one has a short horizon for giving up, and you see if it got close to a candidate target position before giving it to the long-running IK.

[PARKBONG]

thank you for your detailed answer!

I have one more question,
What is the simplest way to check whether a target position is going to be outside the workspace?
Can you provide some exmaple codes or links?

thanks you.

[arudich]

I meant that for a specific robot, you as the programmer would be able to make some simple sanity checks. There is not a general tool for this in Isaac Sim right now. Looking at your specific robot, you can probably make a pretty accurate bound for the workspace because the finger is only three revolute joints moving in a parallel plane attached to the knuckle. So the furthest the tip of the finger could be from the knuckle is if the finger is straight. And the finger tip is somewhere on a plane relative to the knuckle. So the valid workspace coordinates are probably somewhere within a circle of radius finger_length around the knuckle.