ComputeJointVelocityFromTwist fails on continuous joints about prpy

[cdellin]

Random code comments: (a) index -> q_index, (b) xrange -> enumerate.

[cdellin]

Also (c) IsContinuous() -> IsCircular().

[psigen]

Agree with the philosophy, Inf on continuous makes sense to me.

Will look at code prettification in depth later. Think you can probably
make a pretty boolean array and slice it like:

is_continuous = [robot.GetJointFromIndex(i).IsCircular() for i in
robot.GetActiveDOFIndices()]
q_min[is_continuous] = -numpy.inf
q_max[is_continuous] = numpy.inf

On Wed, Feb 25, 2015 at 4:26 PM, cdellin [email protected] wrote:

Random code comments: (a) index -> q_index, (b) xrange -> enumerate.

—
Reply to this email directly or view it on GitHub
#61 (comment)
.

[mkoval]

@cdellin Thanks!

@psigen That's not possible. IsCircular can theoretically be different for each DOF of a multi-DOF joint. E.g. you could have a 3-DOF spherical joint where only a subset of the DOFs are continuous. I don't think we can do much better than what I listed above if we want to handle this case.

[siddhss5]

LGTM.
We should run a contest for the prettiest list comprehension of the above code :).

[cdellin]

Best I could do:

q_min, q_max = robot.GetActiveDOFLimits()

jointof = robot.GetJointFromDOFIndex
iscirc = lambda d: jointof(d).IsCircular(d-jointof(d).GetDOFIndex())
q_circ = [iscirc(d) for d in robot.GetActiveDOFIndices()]
q_min[q_circ] = -numpy.inf
q_max[q_circ] =  numpy.inf

[sjavdani]

Shouldn't this be changed higher in the chain? That is, shouldn't
GetActiveDOFLimits() return +-numpy.inf when IsContinuous is true?

On Wed, Feb 25, 2015 at 5:31 PM cdellin [email protected] wrote:

Best I could do:

q_min, q_max = robot.GetActiveDOFLimits()

jointof = robot.GetJointFromDOFIndex
iscirc = lambda d: jointof(d).IsCircular(d-jointof(d).GetDOFIndex())
q_circ = [iscirc(d) for d in robot.GetActiveDOFIndices()]
q_min[q_circ] = -numpy.inf
q_max[q_circ] = numpy.inf

—
Reply to this email directly or view it on GitHub
#61 (comment)
.

[psigen]

That's an interesting point, @sjavdani. This seems like a case where changing to the intuitive behavior in our OpenRAVE fork might be The Right Thing™.