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

Robot position variables are always required to be a 16-dim vector + robot DoFs #82

Open
francesco-romano opened this issue Mar 3, 2015 · 2 comments

Comments

@francesco-romano
Copy link
Contributor

All the blocks which require a position input have dimension 16 + DoFs.
The 16 dim is the Frame object associated with the base.

I think we should move to use quaternion + displacement (then dim = 7) instead of specifying the whole matrix (which in my opinion does not make any sense because it is not a free matrix. There are constraints on the values we can put into it)

cc @DanielePucci @traversaro

@naveenoid
Copy link

Popping in because of a prior discussion with @traversaro. I personally
prefer rotation matrix as it leaves a simple typecast to a Frame object
available to the end user. Even a quaternion is not a free R^4 vector, it
is constrained. However quaternion has an issue that its not obvious unless
someone looks up documentation if its a axis-angle or a quaternion. Even
then, there are 2 quaternion conventions : real followed by imaginary
vector and vice versa. So could lead to misunderstandings...On the other
hand there is the advantage of number of variables returned...


Naveen Kuppuswamy, PhD
Post-doctoral Fellow,
Cognitive Humanoids Lab,
Department of Robotics, Brain and Cognitive Sciences (RBCS),
Istituto Italiano di Tecnologia, Genova, Italy

On Tue, Mar 3, 2015 at 9:21 AM, Francesco Romano notifications@github.com
wrote:

All the blocks which require a position input have dimension 16 + DoFs.
The 16 dim is the Frame object associated with the base.

I think we should move to use quaternion + displacement (then dim = 7)
instead of specifying the whole matrix (which in my opinion does not make
any sense because it is not a free matrix. There are constraints on the
values we can put into it)

cc @DanielePucci https://github.com/DanielePucci @traversaro
https://github.com/traversaro


Reply to this email directly or view it on GitHub
#82.

@DanielePucci
Copy link
Contributor

I prefer the element of SE(3) as input. What do you think of separating the orientation-translation of the base from the joint positions? In this case, we may take as input a 3x4 matrix (i.e. [R,t]) and an nth dimensional vector (i.e. qj).

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