Consider a bimanual robot with Shadow robot hands attached to each arm. This will end up in a complex kinematic tree. We defined groups for both arms (ra1 and la1) for the 7-DoF arms (from base up to tool mount). Further, we defined groups (ra2 and la2) for the arms that also include the two additional wrist joints in the Shadow robot hand (i.e. 9-DoF chains each). Each of those groups have got a separate kinematics solver defined.
Both variants (1 and 2) are combined in separate groups bi1 = [ra1, la1] and bi2 = [ra2, la2] using subgroups.
When associating kinematics solvers to the master groups bi1 and bi2, always the solvers for ra1 and la1 are used. However, I would expect the bi2 group to use solvers from ra2 and la2.
The reason for this behaviour can be found in RobotModel::setKinematicsAllocators:
Because - naturally - there is no solver defined for the master groups, search proceeds for subgroup solvers. However, this search scans all available solvers by group name, finding ra1 and la1always beforera2 and la2.
As the associated joints are a subset of ra2/la2 joints, the corresponding solver is used every time.
Actually, I would expect, that the associated sub groups will be scanned (instead of comparing joint sets).
Of course, this enforces to use subgroups to define the top-level groups.
If you are OK with this constraint, I could create a pull request to solve this issue. After checking the subgroups, one could still keep the old code to realize the matching on the joint level...
@guihomework: Actually, the problem is somewhat artificial, because all arm groups currently use the same kinematics settings. However, that might change in the future...
mikeferguson
commented
8 years ago
Consider a bimanual robot with Shadow robot hands attached to each arm. This will end up in a complex kinematic tree. We defined groups for both arms (
ra1andla1) for the 7-DoF arms (from base up to tool mount). Further, we defined groups (ra2andla2) for the arms that also include the two additional wrist joints in the Shadow robot hand (i.e. 9-DoF chains each). Each of those groups have got a separate kinematics solver defined.Both variants (1 and 2) are combined in separate groups
bi1 = [ra1, la1]andbi2 = [ra2, la2]using subgroups.When associating kinematics solvers to the master groups
bi1andbi2, always the solvers forra1andla1are used. However, I would expect thebi2group to use solvers fromra2andla2.The reason for this behaviour can be found in
RobotModel::setKinematicsAllocators: Because - naturally - there is no solver defined for the master groups, search proceeds for subgroup solvers. However, this search scans all available solvers by group name, findingra1andla1always beforera2andla2. As the associated joints are a subset ofra2/la2joints, the corresponding solver is used every time.Actually, I would expect, that the associated sub groups will be scanned (instead of comparing joint sets). Of course, this enforces to use subgroups to define the top-level groups. If you are OK with this constraint, I could create a pull request to solve this issue. After checking the subgroups, one could still keep the old code to realize the matching on the joint level...
@guihomework: Actually, the problem is somewhat artificial, because all arm groups currently use the same kinematics settings. However, that might change in the future...