Feature request: More joint types

[ARanvik]

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?

[tkoolen]

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]

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.

[JurajLieskovsky]

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]

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.

[JurajLieskovsky]

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]

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

from Featherstone's book.

I'll take a look at your work.

[tkoolen]

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

[JurajLieskovsky]

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

[JurajLieskovsky]

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.