# Ikfast computation time

The average time calculation in http://kaist-ros-pkg.googlecode.com/s... Says milliseconds but it seems to me it should be microseconds.

Shouldn't it be microseconds? Can anyone clarify this for me?

edit retag close merge delete

As this is purely an OpenRave/IKFast question, I think you'd better ask this on openrave-users (which I believe you already found).

As to your code: it is really old (2012), so it might be that in newer versions it has changed.

( 2015-09-06 00:59:32 -0600 )edit

Hi gvdhoorn, I posted the question here because this code was given in ROS wiki http://wiki.ros.org/Industrial/Tutori...

( 2015-09-06 04:35:42 -0600 )edit

That still doesn't make it a ROS problem. All that code was generated by OpenRave scripts, not ROS.

In more recent OpenRave distributions, I'd guess.

( 2015-09-06 05:14:33 -0600 )edit

Ok........

( 2015-09-06 06:07:21 -0600 )edit

Sort by » oldest newest most voted

Note OpenRAVE still is maintained and actively developed, but moved to github some time ago ( https://github.com/rdiankov/openrave ). What is true is that there hasn't been a official release for some time, however.

How much time ikfast computation takes is highly dependent on the kinematics of your manipulator. There are cases where computation takes few microseconds (typically 6DOF arm, nicely intersecting axes) and cases where it takes a few milliseconds (dealing with complicated kinematics, more or less than exactly 6DOF). In the "hard" cases, the success rate often is lower, too (or the ikfast generator fails to generate a solution at all). These are rules of thumb however, you really have to test this for the kinematics you're looking at to be sure.

more

OpenRave is not being actively developed anymore, as far as I know. The latest release is 0.8.2 which is 3 years old. Nevertheless, official Wiki on IKFast states:

The closed-form code generated by ikfast can produce solutions on the order of ~4 microseconds! As a comparison, most numerical solutions are on the order of 10 milliseconds (assuming good convergence).

Also, I have done some tests about a year ago both on x86 (Intel i7, 4 cores + HT) and on ARM (Xilinx Zynq 7000, 2 cores). Kinematics model is a typical 6-DOF KUKA and IKFast solver is Transform6D. So the figures were as follows:

x86

-- Forward kinematics
Overall time: 54570 us
Samples: 300000
Min: 0 us
Max: 72 us
Avg: 0 us

-- Inverse kinematics
Overall time: 3146303 us
Samples: 300000
Min: 2 us
Max: 78 us
Avg: 10 us


Xilinx Zynq:

-- Forward kinematics
Overall time: 1152121 us
Samples: 300000
Min: 3 us
Max: 93 us
Avg: 3 us

-- Inverse kinematics
Overall time: 24644975 us
Samples: 300000
Min: 40 us
Max: 831 us
Avg: 82 us


The zeros in results for x86 are due to rounding.

These test were done to get a rough idea on timing/latencies distribution for real-time control. I also have somewhere the data for Xilinx Zynq with Xenomai patched kernel, so if you are interested I will try to find it.

Here is also timing distribution for IK on Zynq without Xenomai:

more