Trouble with theta in the kinematic model....

694 views
Skip to first unread message

Greg

unread,
Jun 12, 2009, 2:38:41 PM6/12/09
to Robotics Tool Box
Dear all,

I have only recently started using the Robotics Tool Box, but have
come to a problem that I believe to be linked with the kinematic model
of the robot arm I am working with.

Based on the puma560.m file that is included in the download, I have
modified it for my arm. I won't paste the whole file here, but will
paste the link parameters part below:

clear L
% link([alpha A theta D sigma], CONVENTION)
L{1} = link([ 0 l3 3*pi/2 0 0], 'standard');
L{2} = link([ 0 l2 3*pi/2 0 0], 'standard');
L{3} = link([ 3*pi/2 l1 0 0 0], 'standard');
L{4} = link([ 0 l0 0 0 0], 'standard');
%L{6} = link([ 0 0 0 0 0], 'standard');

The problem seems to be with the model angles, theta in particular.
When plotting this model in simulink, no matter what theta values I
put in the above model (currently 1 and 2 are 3*pi/2), the initial
position of the arm is always completely horizontal. Even when
changing the initial position in the jtraj and Robot simulink blocks,
there is no variation in the plotted orientation of the arm's initial
position. However, adding a different final position in the jtraj
block does slowly move the arm from the initial position (straight
horizontal alignment) to whatever final orientation I selected. It's
just that the starting orientation is always wrong.

Along those lines, the Puma560 model has thetas all set to 0, all
initial joint positions in the demo3 model set to 0, yet the initial
orientation of the arm certainly has joints at non-flat angles. How
are these set in the initial orientation?

I assume there must be a setting somewhere that I haven't found. Does
anyone have a suggestion for what I'm doing wrong?

Cheers,
--Greg

Peter Corke

unread,
Jun 22, 2009, 2:32:09 PM6/22/09
to robotics...@googlegroups.com
The DH parameters in the model comes from the values initialized in the
link objects. For revolute joints, like for the Puma, the initial
values of theta come from here.

But the functions that use the robot model actually take the values for
theta from the passed joint coordinate argument. So if joint is
revolute it substitutes q for theta, if prismatic it substitute q for
d. This is actually done in the link object itself, since mostly we are
interested in a link transform matrix A, so the object abstracts all this.

I'm not sure what you're doing in Simulink, but bottom line is that the
robot object elements are never updated unless you do so.

peter.

Peter Corke

unread,
Nov 14, 2009, 4:54:59 AM11/14/09
to Mike, robotics...@googlegroups.com
Mike,
> I don't know whether this should be a new thread, but it seemed
> related to Greg's question...
>
> I'm using your latest Matlab code. I'm unable to see a change in the
> coordinates (when I plot) when I give a link a theta angle. For
> instance, the following single link L1 rotates the Z axis around the X
> axis as expected:
>
> L1 = link([ pi/2 0 0 540]);
> robo1 = robot({L1},'base');
> figure;
> plot(robo1,[0]);
>
> % But now add another link, giving -pi/2 for theta:
>
> L2 = link([ 0 0 -pi/2 134]);
> robo2=robot({L1 L2}, 'arm');
> figure;
> plot(robo2,[0 0]);
>
so what about:

plot(robo2, [0 -pi/2]) ??

As per my previous reply:


> But the functions that use the robot model actually take the values for
> theta from the passed joint coordinate argument. So if joint is
> revolute it substitutes q for theta, if prismatic it substitute q for
> d. This is actually done in the link object itself, since mostly we are
> interested in a link transform matrix A, so the object abstracts all this.

So plot is a function that uses the robot model. You have asked it to
substitute 0 for theta in each joint (since they are both revolute).
When you create a link object either of d or theta is irrelevant
(depending on whether it is prismatic or revolute respectively).

Looking at this thread it seems this causes a lot of confusion. The
options are to have different arguments for each of the prismatic and
revolute cases so that in Mike's example he'd just write:

L2 = link([ 0 0 134]);


But I was trying to keep the API simple and consistent...

We could also use the Matlab string/value convention:

L2 = link('revolute', 'alpha', 0, 'a', 0, 'd', 134);

and it would complain if theta was specified for this revolute joint:
you get an error message instead of confusion.

What do people think?


peter

Mike Howard

unread,
Nov 14, 2009, 12:19:35 PM11/14/09
to robotics...@googlegroups.com
You say the theta in the link command is irrelevant because you simply
substitute the given q for the theta (of an R joint). But my understanding
of D-H is that theta in the link command should actually revolve the X joint
coordinate axis about the Z axis. So any given q should be added to the
theta of the link command, not substituted.

Otherwise, there is no way to store the 0 position of each joint in the
model... I would have to save it outside the model, and adjust any incoming
q before applying it to the model, right? I think that's what you're
telling me when you say to call plot like this: plot(robo2, [0 -pi/2]).

Peter Corke

unread,
Nov 14, 2009, 4:25:19 PM11/14/09
to robotics...@googlegroups.com, Mike
The link object has an offset parameter, so you could do:

L2.offset = -pi/2;

to achieve what you want.

I was trying to be pure with respect to D&H conventions as they are
widely understood. However a big problem, one that always trips people
up, is the zero-angle pose. The D&H conventions define the pose of the
robot for joint angles of zero, which is rarely how people envisage or
design the zero-angle pose. The offsets were introduced into the
toolbox quite a few versions ago to fix that (but always the curse of
backward compatability).

It would perhaps be cleaner to consider that q is added to that the
values defined in the link as you thought was the case, but in my
experience this would just trip up a different group of users...

D&H conventions are covered in every textbook and taught in most
courses, but I find them very unintuitive, and my hunch is that
everybody curses them. They do however lead to nice formulations for
dynamics, Jacobians etc.

An alternative is to just write down a string of simple transformations
that define the robot, and then factor the D&H parameters out from that,
check out:

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4252158

peter.

Reply all
Reply to author
Forward
0 new messages