Library for inverse kinematics?

    Hi,

    I have noticed that in RoboDK, one can see a list of all of the possible configurations of the robot for the current pose.

    Do any of you know a software library that can generate a list of all of the inverse kinematics solutions like that? Finding one inverse kinematics solution is not a problem, but I want to be sure that I have all of the solutions, so that I can choose the one that fits the use case best. The library should work with both robots with spherical wrists (e.g. KUKA), but also robots like UR. So far we have used different solvers from ROS, but none of them give us all solutions, only one solution.

    Ideally we would like to use the solvers that RoboDK uses, but I suspect that they are not willing to let people use the RoboDK solver in other products.

    Thanks in advance!

    /RoboticsMan

    You simply can check with RoboDK for the answer.

    What language of the library you actually looking for (python, c#, c, c++, vb, modula2)?

    You also did not mention for how many different robots you want this library.

    Another way would be simply trying to create the library yourself.

    On the Internet (Github and others) you may find docs and code on how to it.

    Hi,

    Thanks for the answer.

    We are coding in C++, so the library would have to be in C++, or we would have to make a C++ wrapper.

    With regards to how many types of robots - well... ideally all 6-axis robots?

    And we already did make a solver (both analytical and numerical plus an algorithm for deducing the DH parameters from a physical robot) ourselves, and it works well with more or less any 6-axis robot (any KUKA, FANUC, ABB, UR etc), but it has some limitations that we would like to avoid in the new project - and it would be nice not to have to have to maintain a solver library ourselves going forward. We have switched to ROS and MOVEIT, but so far we are less than impressed, and are looking at what other options there are.

    /RoboticsMan

    A few years ago, I cam across an open-source SciLab library for building DH models and doing inverse and forward kinematics. Didn't get time to play with it much.

    The main issue here is that you're going to have to build DH models for every variety of arm design (look at the wrist of a Fanuc R-2000 vs the wrist of a UR-10, for example). And then parameterize those models for every variation that falls under the differnt DH model.

    Quote from SkyeFire

    A few years ago, I cam across an open-source SciLab library for building DH models and doing inverse and forward kinematics. Didn't get time to play with it much.

    The main issue here is that you're going to have to build DH models for every variety of arm design (look at the wrist of a Fanuc R-2000 vs the wrist of a UR-10, for example). And then parameterize those models for every variation that falls under the differnt DH model.

    Hi,

    We already developed code that can determine DH models and do forward and inverse kinematics. It works fine for both Fanuc and UR robots. The problem is just that we want to be able to derive ALL of the solutions for a given target coordinate, and our algorithms are not able to do that.

    /RoboticsMan

    Quote from RoboticsMan

    We already developed code that can determine DH models and do forward and inverse kinematics. It works fine for both Fanuc and UR robots. The problem is just that we want to be able to derive ALL of the solutions for a given target coordinate, and our algorithms are not able to do that.

    Any IK solution inherently has multiple possible solutions. How does your current algorithm pick one currently?

    The brute-force solution would be to run your algorithm across the entire solution space until all possible solutons are found. Not exactly a good solution, though. A somewhat more elegant method would be to run your existing algorithm, find the first solution, then use the first solution to create some reduced potential solution spaces for the alternates -- for example, take the first solution, flip the wrist 180deg, then check that solution for validity. Repeat for A4, A6, A1. Creating an "invert elbow" check would be more involved, but should be doable.

    "How does your current algorithm pick one currently?"

    We find an initial solution with an analytical solver. We have limited the solution space by not allowing the robot to flip wrist, elbow etc (joint limits are automatically generated in our software when the DH parameters are determined). This means that there generally only is one solution (except for the cases where A6 can be turned 360 degrees and still be within joint limits. In that case we have an algorithm for which solution to choose).

    In our new software, we would like to avoid limiting the joints like that, we want to be able to use the robot it its entire working range.

    To do inverse kinematics for robots a first step would be to define the type of robot:
    - How many axes
    - Type of axis (Rotation, Translation)
    - Wrist center point (yes/no)

    Starting with Standard Robot (RRR RRR and WCP) you have 8 mechanical solutions (A1, A3, A5),
    depending on A1, A4, A6 (up to 48 solutions)!

    Depending on PTP or LIN (depending on robot manufaturer) there will be some limitations:

    PTP:
    - Position of axis (positiven negative)
    - Position of A1, A3, A5)

    LIN:
    - Soft-/hardware limit switches
    - L2 to prev pos

Advertising from our partners