Robotology
Replies: 2 comments 1 reply
-
|
Nice writeup @Woolfrey 👍🏻 My educated guess is that, compared with the other more industrial manipulators, the iCub arm is kind of penalized in terms of both size and range of motion for some of the joints and specifically for the shoulder roll and the wrist yaw, especially when considering the area in front of the robot where objects are mostly supposed to lie for manipulation purposes. However, as you said, if we enable the torso joints the story changes quite considerably. Here's below the manipulability for the 10-DOF chain [code, data].
As it's visible, numbers are much better now. Ipopt doesn't deal directly with the inversion of the kinematic Jacobian, being a state-of-the-art interior-point primal-dual method for nonlinear constraint optimization. This is just to give a shallow hint on the fact that Ipopt tends to outperform traditional IK methods also in the 10-DOF configuration (see this resource), right because Jacobian-based approaches can get trapped bumping into joint bounds when possible paths to the solution may be found only by exploring directions not proposed by the Jacobian per se. |
Beta Was this translation helpful? Give feedback.
-
Summary
I decided to do a further analysis comparing the iCub 2 and iCub 3, and then the iCub 3 with and without the torso. Below are some basic statistics summarising the manipulability between them:
Interestingly, the iCub 2 has a better maximum manipulability than the iCub 3. Although, this could be because discretized joint combinations are used so the "best" configuration might not have been captured for the iCub 3. Confirming @pattacini's previous post, the inclusion the torso joint dramatically increases the manipulability. iCub 2 vs iCub 3 (Left Arm)Below is a histogram of the manipulability for both the robots using 6 equispaced joint positions between limits (6^7 = 279, 936 combinations). The distribution for v3 is less skewed, resulting in a higher median value. This means the iCub 3 has more joint configurations with better manipulability. If I am not mistaken, this is because the iCub 3 has slightly longer limbs which means a smaller change in the joint angles is required to produce the same motion at the hand.
Here is a point cloud comparing the workspaces, coloured by manipulability (hopefully I got the dimensions correct). The iCub 3 has a larger workspace. More interestingly, the regions of greatest manipulability are in front of the robot - where one might expect to be doing the majority of manipulation tasks.
Including the TorsoThe torso adds 3 additional joints to the kinematic chain. For this analysis, I used 4 equispaced joint positions between the upper and lower joint limits. I excluded the first joint to reduce the computational cost since it can be proved that:
In total there were 4^9 = 262, 144 combinations. Below is a histogram comparing the range of manipulability for the iCub 3 arm with and without the torso joints:
There is a much more even distribution, but also many more joint combinations with better manipulability. This means it is easier to find joint configurations that are non-singular, making it easier to solve the inverse kinematics. Moreover, there are more feasible solutions within the joint limits. Here is a point cloud of the workspace when including the torso:
The region with better manipulability (green) is much larger than before. Moreover, it appears to cover the area to the front of the robot which would be the ideal workspace for object manipulation. Note that since the volume of the workspace could be dramatically increased by including the first joint (though this would require over 1 million joint configurations to be computed). ConclusionAs @pattacini previously confirmed, using the torso on the iCub is essential for using inverse kinematics. It not only increases the workspace, but also the manipulability. It also provides 3DOF of redundancy that can be utilized for optimising the joint configuration (joint limit avoidance, singularity avoidance, energy minimization, etc.). What remains to be investigated is the two-handed manipulation. The extra range of motion afforded to a single arm is negated if both hands need to maintain good manipulability. This might be worth analysing in the future. |
Beta Was this translation helpful? Give feedback.
-
For this, you may reach out to the AMI group for their work on lifting a weight with 2 hands. (cc @DanielePucci @lrapetti) Also, find below a couple of works we did in the past to address the IK of a bimanual task:
Footnotes
|
Beta Was this translation helpful? Give feedback.
-
Summary:
Background:
I am part of the ergoCub project and have been using the iCub to develop a Cartesian controller for manipulating objects. The velocity of the hand is related to the joint velocities by the Jacobian matrix:
A general solution for the joint velocities to control the speed of the hand takes the form:
where the pseudoinverse is:
Two problems can occur:
A solution is to use damped least squares when near singularities. This causes task error, but avoids instability. It can be activated at a threshold value to preserve accuracy where possible. I found that the iCub was often near-singular and would rarely execute a hand motion accurately.
I decided to investigate.
Measuring Proximity to a Singularity:
The manipulability index is given by:
which is the product of singular values of the Jacobian. Hence, at a singularity, mu = 0. In my experience, mu > 0.01 is quite good.
I reconstructed a kinematic model of the iCub arm (v2) in MATLAB based off the DH parameters (excluding the torso links). For each joint, I iterated through 6 equispaced positions between limits, for a total of 6^7 = 279,963 possible joint configurations. I computed the manipulability indexf or each.
NOTE: Self-collisions are not accounted for, so not all configurations are feasible.
I compared these values to other commercially available robot arms:
Here some basic statistics on the manipulability for each of the arms:
*only non-zero values were used to compute the median.
And here is a histogram showing the distribution of values:
As can be seen, the distribution for the iCub arm is left-skewed. The Jacobian is almost always ill-conditioned. This makes it very difficult to apply classical inverse kinematics methods for controlling the hand. This could be an issue for Cartesian impedance control, since the Cartesian inertia matrix is also computed with the Jacobian:
Examining the Workspace:
I computed the hand position of the iCub arm for every configuration. I then generated a point cloud for each hand position, using the manipulability index to colour the points: green is good, red is bad (MATLAB wouldn't let me plot a model of the arm and use colour scales simultaneously for some reason):
The general working position for the iCub when manipulating objects is down and toward the front. This region has poor manipulability. Ironically, the best manipulability appears to be up near the head. Of course, the workspace of the arm can be moved by moving the torso.
Conclusions:
Beta Was this translation helpful? Give feedback.
All reactions