Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Continuous joints with joint limits #289

Closed
wxmerkt opened this issue Nov 24, 2019 · 6 comments · Fixed by #347
Closed

Continuous joints with joint limits #289

wxmerkt opened this issue Nov 24, 2019 · 6 comments · Fixed by #347

Comments

@wxmerkt
Copy link

wxmerkt commented Nov 24, 2019

Most URDFs in this repository contain joints (e.g., 1, 3, 4, 6 depending on which URDF) that indicate that they are of type "continuous", but then specify upper and lower position limits. I think these joints should be changed to "revolute" if they specify limits.

Some of this appears to have been introduced in b88bfc1 as a work-around. I believe all continuous joints that specify limits should be changed to revolute - or is there another reason to have them as "continuous"?

Related:

@alexvannobel
Copy link
Contributor

Hi @wxmerkt ,

You are right, the continuous joints should not use lower and upper position limits. However, since the xacro architecture was made to have only one macro for a kinova_armjoint, I'm a bit reluctant to change that. I could add an <if [...]> in the macro calls and in the macro ifself to check for continuousorrevolute`, but I think that would become quite heavy for a very small gain.

The joints are truly continous in the robot, so I wouldn't change that for sure.

In the URDF documentation for the <joint> tag, it says to omit the upper and lower limits when using continuous. If we absolutely have to omit them (but I would make the assumption that continuous joints simply don't parse those tags), then this would be a bug and we would change the kinova_description package. Else, as I said, I don't see much gain in changing the descriptions.

What are your thoughts on that?

Best,
Alex

@wxmerkt
Copy link
Author

wxmerkt commented Dec 2, 2019

Hi Alex,
Thank you very much for your response. Some URDF parsers use SO(2) groups when the type is continuous - this will not work with limits.

As such, if limits are to be imposed (e.g., to not over-stretch cables), I think the type should be changed to revolute. Are there any hardware reasons (cables?) to have them with limits rather than without? If they have transfer rings so that they aren't any limits, it would be good to remove the limits tags to avoid confusion.

Does this make sense?

Best,
Wolfgang

@felixmaisonneuve
Copy link
Contributor

This thread has being inactive for over a year, I am closing this issue. If there is still a problem, please create a new issue.

Thank You

@wxmerkt
Copy link
Author

wxmerkt commented Jun 4, 2021

Hi @felixmaisonneuve
The issue has not been resolved: The joints should either be a revolute joint with limits (even if large) or a continuous joint without position limits.

@felixmaisonneuve
Copy link
Contributor

Hi @wxmerkt,
And as Alex explained, some joints are fully continuous, meaning they do not need lower and upper limit.
However, we define each joint as a kinova_armjoint. This object has to have an upper and lower limit, regardless of the type the joint is (revolute or continuous). Even if continuous joints should not use them.
You can find the definition of the kinova_armjoint in kinova-ros/kinova_description/urdf/kinova_common.xacro.

What you say is right, it can be confusing, but I don't think it will be a source of error within a program. If the joint is continuous, the limit should be ignored (which is good, since limits are meaningless in those cases)

I hope this is a clear explanation. Is there some cases where putting unnecessary limits on continuous joint might cause an error?

@wxmerkt
Copy link
Author

wxmerkt commented Aug 7, 2021

Hi @felixmaisonneuve,
Thank you for looking into this. I just opened #347 that fixes this issue while keeping the current macros. It's been almost two years since I opened the issue and I do not recall the specific failures we saw in consumers of the URDF, but that we had to modify the URDFs as highlighted to address them. The PR should fix the issue without changes to the existing behaviour

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants