Review and Unify TEO model joint limits

[PeterBowman]

Original issue: roboticslab-uc3m/kinematics-dynamics#31

Robot model joint limits reference should be in https://github.com/roboticslab-uc3m/teo-software-manual/blob/master/appendix/a-teo-diagrams.md

The following is a list of models to potentially be updated.

• [x] .ini of launch files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchManipulation and https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchLocomotion
• [x] .ini of kinematics files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/kinematics
• [x] Openrave models: https://github.com/roboticslab-uc3m/teo-openrave-models
• [x] Gazebo models: https://github.com/roboticslab-uc3m/teo-gazebo -> https://github.com/roboticslab-uc3m/teo-gazebo/issues/5
• [x] ROS URDF model: https://github.com/roboticslab-uc3m/teo-ros-simulation -> https://github.com/roboticslab-uc3m/teo-ros-simulation/issues/4
• [x] ArmarX models: https://github.com/roboticslab-uc3m/teo-simox-models -> https://github.com/roboticslab-uc3m/teo-simox-models/issues/3

[PeterBowman]

From @RaulFdzbis on May 3, 2016 12:34

Gazebo model and Ros Gazebo model, were already updated in 7718f22 and a6199bc with the joint limits used by the KdlSolver in teo_main.

[jgvictores]

Blocked by https://github.com/roboticslab-uc3m/teo-software-manual/issues/10 as the entry point will be teo-software-manual

[jgvictores]

Unblocked. We should put the official values at: https://github.com/roboticslab-uc3m/teo-software-manual/blob/master/appendix/a-teo-diagrams.md

[jgvictores]

Have to consult if the joint limits currently at: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/kinematics are the ones that should be copied to the official value place: https://github.com/roboticslab-uc3m/teo-software-manual/blob/master/appendix/a-teo-diagrams.md

[rsantos88]

I saw that those limits (at https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/kinematics) are not the same as the .ini values

[jgvictores]

Not very sure to what you refer. Updated top description:

Robot model joint limits reference should be in https://github.com/roboticslab-uc3m/teo-software-manual/blob/master/appendix/a-teo-diagrams.md

The following is a list of models to potentially be updated.

• .ini of launch files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchManipulation and https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchLocomotion
• .ini of kinematics files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/kinematics
• Openrave models: https://github.com/roboticslab-uc3m/teo-openrave-models
• Gazabo models: https://github.com/roboticslab-uc3m/teo-gazebo-models, teo_batc: (Gazebo model), (ROS Gazebo model).
• ArmarX models: https://github.com/roboticslab-uc3m/teo-simox-models

[jgvictores]

Note that maximum velocities and accelerations are also relevant!

[jgvictores]

Blocked, because ideally we would get these values from the real robot, which is currently being modified, see issues on https://github.com/roboticslab-uc3m/teo-hardware-manual

[AlvaroMartinezR]

What a coincidence, I was talking about the limits of TEO yesterday with @smcdiaz and he said thet the best I idea will be to test and obtain the values from the actual real robot like @jgvictores said:

Blocked, because ideally we would get these values from the real robot, which is currently being modified, see issues on https://github.com/roboticslab-uc3m/teo-hardware-manual

The actual status of the robot only allow us to operate with locomotion, he has no arms. @rsantos88 and me are going to do it.

ArmarX models: https://github.com/roboticslab-uc3m/teo-simox-models

PS: I am responsible for teo-simox-models so next time assign or mention me please.

[jgvictores]

PS: I am responsible for teo-simox-models so next time assign or mention me please.

@AlvaroMartinezR No problem! Just in case, I would also recommend you to watch this repo. :-)

[AlvaroMartinezR]

Blocked (again) by https://github.com/roboticslab-uc3m/teo-main/issues/29

[rsantos88]

@AlvaroMartinezR and me have collected all the mechanical limits from the real robot. See the table below:

Joint mechanical limits

Limb	Link	Upper limit	Lower limit
Right arm	1	103.075569	-93.479797
	2	-80.474518	34.622143
	3	85.149384	-62.021088
	4	88.488579	-37.943756
	5	79.701233	-54.376099
	6	112.478027	-61.933228
Left arm	1	-98.488586	92.618629
	2	79.525482	-34.253082
	3	-87.504395	59.753952
	4	-106.133575	19.156414
	5	-81.441132	74.604568
	6	-108.945526	64.850616

Also with the plate for teo-waiter:

Limb	Link	Upper limit	Lower limit
Left arm	6 with plate	-57.803162	65.641472

Now, we are going to polish them: lower them and make them symmetric. Lower them because these are the absolute mechanical limits, working with them will be quite dangerous for TEO. You can see the actual results here. The joint limits are quite high. What do you think about them? For example:

Limb	Link	Upper limit	Lower limit
Right arm	1 (Raw values)	103.075569	-93.479797
Right arm	1 (Edited)	90	-90

[jgvictores]

Proposal: hard limits vs soft limits, documenting both.

[AlvaroMartinezR]

@jgvictores Yeah, that was the idea, but my question was if you think the thresholds are acceptable.

[jgvictores]

I'd ask @smcdiaz 's opinion on that.

[jgvictores]

Spoken with @smcdiaz Question for starters: Were these values taken via the absolute or relative encoders?

[jgvictores]

A more detailed explanation of what I spoke with @smcdiaz :

1. Determine number of relevant decimal values (depends on abs/rel encoder).
2. Establish a fixed tolerance values.

Example: 103.075569 | -93.479797 -> 1 decimal -> 103.1 | -93.5 -> 5 degrees -> 98.1 | -88.5.

[jgvictores]

((WIP, but legs blocked by issues such as https://github.com/roboticslab-uc3m/teo-hardware-issues/issues/1 from private repo))

[jgvictores]

PD: Can still work on this.

[rsantos88]

Spoken with @smcdiaz Question for starters: Were these values taken via the absolute or relative encoders?

This values have been taken with absolute encoders using torque mode

[jgvictores]

Okay, so this means we shouldn't/can't take the transmission reduction into account.

From the current BOM we have raw CUI AMT 203-V on that side. How much was that, (1024 * 4) pulses/turn? [/me a bit in a hurry to check yarp-devices source code]

[rsantos88]

From the current BOM we have raw CUI AMT 203-V on that side. How much was that, (1024 * 4) pulses/turn?

Yes, from https://github.com/roboticslab-uc3m/teo-configuration-files/blob/762ebe5079e05da38602e21e2feccd9901d8513d/share/launchManipulation/conf/launchManipulation.ini we have 4096 (1024 * 4)

[rsantos88]

Which means 0.088 degree/pulse, so it's safe to say we keep only 1 decimal.

[rsantos88]

I am working in this table with the definitive values here. We should remove this other to avoid duplicate information.

[jgvictores]

Small notice: As a result of https://github.com/roboticslab-uc3m/teo-developer-manual/issues/27 we have merged teo-software-manual and teo-hardware manual, so progress will continue at https://github.com/roboticslab-uc3m/teo-developer-manual

Related: https://github.com/roboticslab-uc3m/teo-developer-manual/issues/33

[rsantos88]

updated .osd file with limit values and exported here in CSV. The values with (*) has been replicated from the other leg

[AlvaroMartinezR]

I have a proposal about the hard/soft limits found here. -First, compare and unify opposite joints, for example: left and right saggital shoulder should have the same limit. -Second, I personally find the limits, even they have been measured and can be phisically achieved are too wide for working with them.

These are my suggestions and ideas, I would like to know what do you guys think.

[jgvictores]

There is a school of thought that believes robots should not be limited to what humans can do, which applies even to humanoid robotics. Imposing human restrictions for reasons other than pure safety would not respect this belief.

I'd agree if these extra artificial constraints were placed in separate new column(s), which could be called "human-inspired joint limits" or similar, but not replacing the existing hard/soft limit columns. Regarding anybody declaring such new columns as useless/redundant/non-informative, perhaps they could be justified if they clearly referenced some kind of medical citation.

[AlvaroMartinezR]

Totally agree, I actually found this, in order to reason the human-inspired limits with medical evidence.

[rsantos88]

updated table here with new "human-inspired joint limits" See the result in .csv format here

[jgvictores]

Looks good! PR? :-)

[jgvictores]

Removed irrelevant comment; 109 is from legs.

[jgvictores]

Merged https://github.com/roboticslab-uc3m/teo-developer-manual/commit/b95ffbf93f2d83c28ebe93eeba34820d7c6d3df8 so branches wouldn't get too messy, but still lots to do here.

Reminder to self: we are working at https://github.com/roboticslab-uc3m/teo-developer-manual/blob/master/assets/src/motores.ods and then updating https://github.com/roboticslab-uc3m/teo-developer-manual/blob/master/assets/motores-motores.csv

[jgvictores]

Point to joint limits at https://github.com/roboticslab-uc3m/teo-developer-manual/commit/7613ae9db87ffc548c93ead66e570659789462e4

[rsantos88]

note: the legs values with asterisk has been replicated from the joints of the other leg

[AlvaroMartinezR]

Ok, now that we have all the values, which ones are we going to use? I mean, this issue is called "unify joint limits", therefore, now that we have all the data, which ones do we put in the inis?

[jgvictores]

I'd recommend putting the Soft. Limits in all the files listed above. :-)

[rsantos88]

• [x] Openrave models: https://github.com/roboticslab-uc3m/teo-openrave-models

Done at https://github.com/roboticslab-uc3m/teo-openrave-models/pull/17

[rsantos88]

• [x] .ini of launch files: https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchManipulation and https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/launchLocomotion

Done at https://github.com/roboticslab-uc3m/teo-configuration-files/pull/5

[rsantos88]

@jgvictores pending of clean some unused files in https://github.com/roboticslab-uc3m/teo-configuration-files/tree/develop/share/kinematics

[AlvaroMartinezR]

@PeterBowman Gazebo models seem quite forgotten, so ask directly to @RaulFdzbis or forget about it

[PeterBowman]

Not my business, I just moved this issue :). Ping OP (@jgvictores).

[AlvaroMartinezR]

Haha ok my mistake then, anyways I didnt meant it to sound mean, only to note that I found it useless if they are not used. Sorry

[jgvictores]

Spoke with @RaulFdzbis today. He's in!

[jgvictores]

@RaulFdzbis Please link to this issue after updating the Gazebo model!

@PeterBowman I'd like to discuss the possibility of removing joint limits from the kinematics .ini used from the solver:

• Reason of being is historic (iCub iKin kinematics file compatibility).
• Reason to remove is because it is duplicate info -> harder to maintain (specially with several versions of kinematics, potentially even after future cleaning).
• Implications are that users like @jmgarciah at teo-waiter apps have to remember to ask the robot for the joints and configure the solver if it is considered necessary (defaults are +-180 deg). I think this is not a bad thing, but maybe some warnings should be set. What is your opinion?

[RaulFdzbis]

So I will update both Gazebo and ROS to the new joint values (I suppose they have changed since here).

The Gazebo model will not be a problem, however modifying the URDF files for ROS could take a little bit of time so be patient! :D

[PeterBowman]

@PeterBowman I'd like to discuss the possibility of removing joint limits from the kinematics .ini used from the solver:

Those .ini values are not used at all, so IMO it's totally reasonable to remove them. Speaking of current cartesian controllers, I'd consider opening the robot device before the solver one, pick actual robot joint limits via IControlLimits interface, and pass them later to the solver upon configuration (e.g. solverOptions.put("min", "whatever")).

One thing to sort out is: should joint limits be constrained as read-only properties in ICartesianSolver?

• Yes, we set them upon device initialization and never modify their values again. ICartesianSolver::setLimits could be either removed or rewritten to hold the corresponding class invariants (= report failure if called more than once, which is perhaps a bit against the purpose of said method).
• No, keep ICartesianSolver::setLimits so that users may call it at will on runtime, but take some care to ensure it'll never fall into race conditions. Similarly, variables holding the kinematic chain have been guarded against such circumstances, recently.

[jgvictores]

@PeterBowman Thanks for confirming that these values are not currently used by the solver(s)! I'll follow the conversation you started at https://github.com/roboticslab-uc3m/kinematics-dynamics/issues/145#issuecomment-367329490.

Ok, to recap on the initial issue:

• [ ] .ini of launch files: @jgvictores must review https://github.com/roboticslab-uc3m/teo-configuration-files/pull/5
• [x] .ini of kinematics files: @rsantos88 can safely delete the joint limit data.
• [ ] Openrave models: @jgvictores must review https://github.com/roboticslab-uc3m/teo-openrave-models/pull/17
• [ ] Gazabo models: will be done by @RaulFdzbis at as a low priority task, tracked at https://github.com/roboticslab-uc3m/teo-gazebo/issues/5
• [ ] ROS URDF model: will be done by @RaulFdzbis at as a low priority task, tracked at https://github.com/roboticslab-uc3m/teo-ros-simulation/issues/4
• [x] ArmarX models: @AlvaroMartinezR maybe you could take a look? (edit: confirmed, yes!)

[AlvaroMartinezR]

@jgvictores Yes, but I am currently working on a paper for iros and since no one uses simox models I will update it as soon as I finish the article.

[rsantos88]

• [ ] .ini of kinematics files: @rsantos88 can safely delete the joint limit data.

I've removed the limits of this files. Are the other files useful? Do you want to delete them? (e.g: leftArm22Kinematics.ini or leftArmKinematics-isolated.ini)