You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current API for inverse kinematics prevents linking a library or executable with more than one type of inverse kinematics. The only way to choose is by defining UR5_PARAMS or UR10_PARAMS, but the kinematic functions end up with the same name so linking both together is impossible.
I would propose to fix this by adding a second overload for each of the kinematics functions accepting an additional parameter containing the kinematic parameters of the robot.
The behaviour of the original function not accepting such a struct can remain unchanged, so that defining UR5_PARAMS or UR10_PARAMS effectively sets the default robot type used when no kinematic parameter struct is given. This way, anything that works now will continue to work the same way.
I believe this can be done without decreasing performance of at least the original kinematics functions, but this should be verified with measurements.
In addition we could define kinematic functions for each of the supported robot types (for example ur_kinematics::inverse5(...)) for easy access and possibly slightly improved performance over the generic functions that accept a kinematic parameters struct (again, should be measured).
I would like to implement these changes and perform measurements, but before starting on them I'd like to know if such changes would be welcome :)
Also, I would like to base this on #218, but that should already be useful on it's own.
The text was updated successfully, but these errors were encountered:
The current API for inverse kinematics prevents linking a library or executable with more than one type of inverse kinematics. The only way to choose is by defining
UR5_PARAMS
orUR10_PARAMS
, but the kinematic functions end up with the same name so linking both together is impossible.I would propose to fix this by adding a second overload for each of the kinematics functions accepting an additional parameter containing the kinematic parameters of the robot.
The behaviour of the original function not accepting such a struct can remain unchanged, so that defining
UR5_PARAMS
orUR10_PARAMS
effectively sets the default robot type used when no kinematic parameter struct is given. This way, anything that works now will continue to work the same way.I believe this can be done without decreasing performance of at least the original kinematics functions, but this should be verified with measurements.
In addition we could define kinematic functions for each of the supported robot types (for example
ur_kinematics::inverse5(...)
) for easy access and possibly slightly improved performance over the generic functions that accept a kinematic parameters struct (again, should be measured).I would like to implement these changes and perform measurements, but before starting on them I'd like to know if such changes would be welcome :)
Also, I would like to base this on #218, but that should already be useful on it's own.
The text was updated successfully, but these errors were encountered: