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

Feature request: More joint types #614

Open
ARanvik opened this issue Feb 21, 2021 · 9 comments
Open

Feature request: More joint types #614

ARanvik opened this issue Feb 21, 2021 · 9 comments

Comments

@ARanvik
Copy link

ARanvik commented Feb 21, 2021

Support for "building" more complex joint types by specifying a sequence of basic joint transformations. For example the 2-DOF finger-ball-socket using two revolute. Or something more complex like 2 rotations + 1 translation + 2 rotations (which could model a driven wire that hinges at both ends).

Question: Alternatively, is there any downsides to using many dummy bodies to model complex joints?

@ARanvik ARanvik changed the title More joint types Feature request: More joint types Feb 22, 2021
@tkoolen
Copy link
Collaborator

tkoolen commented Mar 8, 2021

Right now I unfortunately don't have the time to develop that. However, it's not that difficult to define your own joint type (see e.g. https://github.com/JuliaRobotics/RigidBodyDynamics.jl/blob/master/src/joint_types/prismatic.jl; should be reasonably easy to pattern-match), and things are set up so that anybody can define their own; there's nothing special about the 'built-in' joint types. However, one major restriction is that only joint types with a constant motion subspace are currently supported, so that means that something like a roll-pitch-yaw-parameterized spherical joint with the time derivatives of roll, pitch, and yaw as the velocity variables is not possible, unless you use dummy bodies as you mentioned.

Dummy bodies aren't so bad. You have to be careful to ensure that the mass matrix stays positive definite; one way to ensure that is to give all of the dummy bodies a small amount of inertia, although that isn't always strictly necessary. There's a little bit of a performance loss compared to having a dedicated joint type since the algorithms will transform all of the individual dummy bodies' inertias to a different frame, whereas with a dedicated joint type only the 'real' body's inertia would be transformed, and transforming spatial inertias is somewhat expensive. Definitely viable if you don't have extreme performance requirements though.

@ARanvik
Copy link
Author

ARanvik commented Apr 9, 2021

I'll try to create some new joint types, thanks :-) Will probably use dummy bodies as well in my model for the more complex joints. Will set body inertia as an identity matrix for dummies (the model has otherwise quite large masses so will not affect model that much). I created a new local branch after i cloned your repo, maybe if I get the joint types working they can be merged into master.

@lieskjur
Copy link

lieskjur commented Apr 20, 2021

only joint types with a constant motion subspace are currently supported

Hi, just to clarify. The motion subspace must be constant in relation to the frame before or after the joint?

And are there any plans to remove this restriction? I would like to add involute joints (the evolute being a circle) but one parent-child relationship with this kinematic constraint is impossible due to this restriction if I am not mistaken.

@tkoolen
Copy link
Collaborator

tkoolen commented Apr 21, 2021

The motion subspace must be constant in relation to the frame before or after the joint?

After the joint.

And are there any plans to remove this restriction?

Not currently. I think there's a caching thing related to bias accelerations that needs to be rethought a little and I can't make promises about when I'll have time to do that properly right now.

@lieskjur
Copy link

lieskjur commented Apr 23, 2021

Appreciate the speedy reply.

Regardless I decided to try and create the joint according to your spec.

Do you, by any chance have a reference on bias accelerations? quick search didn't yield anything and judging by the comments in "joint.jl" I would assume they are the sum of coriolis and centrifugal, in which case I am not sure if to include them in "joint_spacial_accelerations" as well.

I think I've got the transformations, twists and accelerations down in general terms but I'm still struggling to understand how the subspaces are defined. If you would be so kind to check if I'm on the right track, here's a link to a branch where you can find derivations along with the work in progress.

https://github.com/lieskjur/CircularEvoluteJoints

PS: probably the i,j,k notation I'm using atm isn't the luckies as they are arbitrary vectors forming an orthonormal system in my current implementation

@tkoolen
Copy link
Collaborator

tkoolen commented May 1, 2021

By bias acceleration I mean the \dot{S}_i \dot{q}_i term in

image

from Featherstone's book.

I'll take a look at your work.

@tkoolen
Copy link
Collaborator

tkoolen commented May 1, 2021

Do you have a reference for the notation you use in that PDF?

@lieskjur
Copy link

lieskjur commented May 1, 2021

Featherstone's book

Will check it out. Thanks.

Do you have a reference for the notation you use in that PDF?

The notation is based on what is used at my university in central Europe so an english reference is out of the question. I added a little preamble at the start of the document though, which I hope will be enough along with the diagram.

Also I moved my progress to a dev clone of your package (including the updated pdf) here: https://github.com/lieskjur/RigidBodyDynamics.jl

@lieskjur
Copy link

lieskjur commented Aug 10, 2021

Featherstone's book is an invaluable resource. For anyone planning on defining their own joint types and is new to spatial vectors I would recommend first getting familiar with spatial accelerations (section 2.12) and how they are derived from spatial velocities (section 2.2). Afterwards coordinate transforms (section 2.8) and spatial vectors in general appear much more useful.

Nevertheless I find Featherstone's joint in example 4.6 (section 4.4) to be derived in a manner which to me seems to have a "chicken or egg" problem. If anyone else were to find it unclear, here is my own take on the example.


Unfortunately the joint I would like to add does not have a constant motion subspace. If joints with such subspaces were to be supported in the future I have some ideas on how to simulate cable-pulley interactions.

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

No branches or pull requests

3 participants