iCub shoulder joint limits imposed by tendons length

[lornat75]

What are the limit joint values that avoid breaking the cables of the iCub shoulders? The Cartesian solver includes these limits, but it could be useful to have them in C or Matlab code for users that want to control the arm in joint space without the Cartesian controller.

cc @pattacini @randaz81

[randaz81]

The module cableLenghtGuard of the old iCubContrib (i.e. in the svn repository) should perform that check. I'm not sure if it is still up and running but it could be a possibile starting point.

[pattacini]

The complete documentation is available from within our wiki. A detailed description of those joints values is included too.

The class exposed by iKin to handle the shoulder's constraints is iCubShoulderConstr.

[Tobias-Fischer]

@martz21 this might be interesting for you

[lornat75]

I took the freedom to clarify some concepts please double check.

[lornat75]

@randaz81 can we resurrect the code from SVN and publish it on github? maybe in the form of a github gist?

[pattacini]

cableLengthGuard is a very old piece of software that, I'm afraid, would no longer run in our present architecture.

I reckon it should suffice to provide the link to the SVN repository: http://sourceforge.net/p/robotcub/code/HEAD/tree/trunk/iCub/contrib/src/misc/cableLengthGuard.

As further remark, cableLengthGuard makes use of an additional GSL package called CQP for quadratic programming.

[pattacini]

We have lately received from people working with iCubGrenoble01 this archive containing two logs of the right arm moving during an experiment. In particular, in the second log (i.e. right-shoulder-2.log) they experienced a shoulder cable break.

Along with the acquisitions, they sent us also a MATLAB script to analyze those data according to the instructions reported in the wiki. I've then slightly modified the script and made it available in the form of a Gist snippet for reviewing purpose.

By running that snippet we obtain the following two graphs:

---

Let's comment these diagrams.

Single joint bounds are overcome!

I've updated the single joint min/max bounds of the script according to those limits stored in the xml file. It comes out that the third joint of the shoulder overcomes its maximum limit in both the logs (see the red dots in the figures). How can it be possible? Is iCubGrenoble01 actually using different limits? Perhaps @randaz81 can shed a light on this.

Relation among original cable length guards and their reduced set

In the figures are drawn both the original and the reduced set of cable length guards, as described in the wiki (which has been recently updated). It seems that the reduced set is sometimes more restrictive (i.e. closer to 0) and could have been beneficial for saving the cable around samples=400, that is when the cable most likely snapped out.
@iron76 is this behavior expected?

Reasons for cable break

The equations outlined in the wiki account for the paths the cables actuating the shoulder cover around the pulleys of the motors and of the joints. Since we have differential actuation, those cable lengths do interact each other, hence we have to enforce such constraints.

However, despite the fact that the constraints are always verified (i.e. the actual minimum of the length guards is always above 0), iCubGrenoble01 broke one of its shoulder's cable.

• Can it be that, after a maintenance, one or more shoulder cables have been replaced with new cables that have non standard lengths?
• Is there any peculiarity with the iCubGrenoble01 shoulders?
• Are the length guards still in line with the CAD drawings?

/cc @robotology/icub-support-team

[EliseiFrederic]

Thanks Ugo. A few elements relative to your analysis :

1. The shoulder cables have been replaced by identical cables, built and referenced at IIT.
2. I cannot check remotely the limits in the xml file on our robot, but they probably match the values in the repository (we did not modify these).
3. Please note that the data in the archive is not a measured trajectory, but the command values sent to generalPlayer to drive the shoulder/arm. They result from a constrained optimization in Matlab (to match a motion-captured human pointing gesture).

[pattacini]

I see, @EliseiFrederic. I actually thought the trajectories were measured. Then, this new information does explain why we have the red dots and might also explain the cable break.

I imagine those set-points will be used to command the shoulder joints, hence an out-of-bound target - along with the profile (velocity) provided to reach it - is likely to cause the break. This scenario is even more likely if the control is done via position-direct mode.

My warm suggestion is therefore to let the MATLAB optimizer be aware of the real limits to never produce out-of-bound targets. We have the yarp::dev::IControlLimits motor interface to retrieve joints limits values on the fly from the robot.

[lornat75]

After some internal discussion there is no agreement on the reason that has caused the tendon to break; looking only at the reference trajectory it is difficult to understand which condition has been violated (and to what extent).

The only suggestion is therefore to include the encoder feedback in the logs (although we do hope the cables do not break again :) ).

@pattacini @randaz81

[randaz81]

Today we just released a new firmware build (83) which provides an improved, bullet-proof check on the limits when controlling a single joint in POSITION_DIRECT mode. I don't know if this applies to your scenario, but I highly recommend to update the robot firmware in any case.

[EliseiFrederic]

Sounds good :-)Thanks Marco for this news
Has any of you dared to check the 2 data files with generalPlayer and this new firmware (while logging the encoder feedback) ? ;-)

[pattacini]

I think most of the progress on this has been happening in robotology/icub-tech-support#103 with @EliseiFrederic and @randaz81.

Closing then; feel free to reopen it.