roboticslab-uc3m / teo-main

TEO full-sized humanoid robot: super/meta repository.
http://roboticslab.uc3m.es/roboticslab/robot/teo-humanoid
GNU Lesser General Public License v2.1
4 stars 1 forks source link

Review and Unify TEO model joint limits #15

Closed PeterBowman closed 5 years ago

PeterBowman commented 7 years ago

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.

PeterBowman commented 7 years ago

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 commented 6 years ago

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

jgvictores commented 6 years ago

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

jgvictores commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

jgvictores commented 6 years ago

Note that maximum velocities and accelerations are also relevant!

jgvictores commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

rsantos88 commented 6 years ago

@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 commented 6 years ago

Proposal: hard limits vs soft limits, documenting both.

AlvaroMartinezR commented 6 years ago

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

jgvictores commented 6 years ago

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

jgvictores commented 6 years ago

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

jgvictores commented 6 years ago

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 commented 6 years ago

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

jgvictores commented 6 years ago

PD: Can still work on this.

rsantos88 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

rsantos88 commented 6 years ago

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

jgvictores commented 6 years ago

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 commented 6 years ago

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

AlvaroMartinezR commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

rsantos88 commented 6 years ago

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

jgvictores commented 6 years ago

Looks good! PR? :-)

jgvictores commented 6 years ago

Removed irrelevant comment; 109 is from legs.

jgvictores commented 6 years ago

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 commented 6 years ago

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

rsantos88 commented 6 years ago

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

AlvaroMartinezR commented 6 years ago

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 commented 6 years ago

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

rsantos88 commented 6 years ago

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

rsantos88 commented 6 years ago

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

rsantos88 commented 6 years ago

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

AlvaroMartinezR commented 6 years ago

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

PeterBowman commented 6 years ago

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

AlvaroMartinezR commented 6 years ago

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 commented 6 years ago

Spoke with @RaulFdzbis today. He's in!

jgvictores commented 6 years ago

@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:

RaulFdzbis commented 6 years ago

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 commented 6 years ago

@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?

jgvictores commented 6 years ago

@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:

AlvaroMartinezR commented 6 years ago

@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 commented 6 years ago
  • [ ] .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)