zapped name typo

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7966 c9849af7-e679-4ec6-a44e-fc146a885bd3
after making (and then locally reverting) a relatively big change, I’ve now just added implementation note:

for homogenous transforms, I could do the following
vector transforms more efficiently.  forwardKin is adding a 1 on
the end of every pt for the homogenous coordinates.  it would be
equivalent, cleaner, and more efficient, to just add a zero on the
end instead of the 1...  because for homogeneous transform matrix
T we have:
   T * [x;1] - T * [0;1] = T * [x;0]
but I made this change everywhere and decided it was more important
to keep the interface to the forwardKin method clean instead of
polluting it (and bodyKin, and the mex files, ...) with an extra
input/option for "vectors_not_points".

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7967 c9849af7-e679-4ec6-a44e-fc146a885bd3
starting to add bertini support.

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7975 c9849af7-e679-4ec6-a44e-fc146a885bd3
minor cleanup of forwardKin

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7976 c9849af7-e679-4ec6-a44e-fc146a885bd3
cleaned up intro documentation

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7977 c9849af7-e679-4ec6-a44e-fc146a885bd3
a little more documentation

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7978 c9849af7-e679-4ec6-a44e-fc146a885bd3
getting ready to try bertini for IK (on a simple acrobot test)

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7982 c9849af7-e679-4ec6-a44e-fc146a885bd3
1. Remove all the constructPtrXXXconstraintmex.cpp and updatePtrXXXconstraintmex.cpp
2. Write a standalone approximateIK and its C++ test function. For the moment I have segmentation fault while setting Q in the objective

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/branches/hongkaidev@7955 c9849af7-e679-4ec6-a44e-fc146a885bd3
1. approximateIK has its standalone C++ version
2. start to add documentation to the C++ RigidBodyConstraint

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/branches/hongkaidev@7970 c9849af7-e679-4ec6-a44e-fc146a885bd3
I have a compile problem in inverseKinBackend when dealing with file scope variables.

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/branches/hongkaidev@7985 c9849af7-e679-4ec6-a44e-fc146a885bd3
Merged from branch 'trunk'

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/branches/hongkaidev@7986 c9849af7-e679-4ec6-a44e-fc146a885bd3
moved dependency grabbing from addpath_drake to checkDependency.  we’re accumulating a lot of dependencies that are only needed for a few methods, and its ridiculous to require them all at startup.

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7991 c9849af7-e679-4ec6-a44e-fc146a885bd3
patch from helping rmli overcome installation issues.

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7992 c9849af7-e679-4ec6-a44e-fc146a885bd3
Russ,

See attachment for a patch that adds a geometricJacobian method to RigidBodyManipulator. I made the patch in the directory drake.

function [J, vIndices] = geometricJacobian(obj, kinsol, base, endEffector, expressedIn)
%GEOMETRICJACOBIAN Computes the geometric Jacobian from base to endEffector
% expressed in frame attached to expressedIn
%   The general contract of this method is that for joint velocity vector
%   v, the twist of endEffector with respect to base, expressed in
%   expressedIn, can be computed as J * (v(vIndices)).

I decided to add the option to specify the frame in which the Jacobian is expressed since it was so easy to add. I was mistaken about the order of omega and v in Featherstone's algorithms, it is indeed [omega; v], so I adopted that as well.

The geometricJacobian method allows you to compute the Jacobian between any two bodies in the kinematic tree, and takes sign changes due to going up and down the tree into account.

I added a test that compares twist = J * (v(vIndices)) to the relative Tdot between random bodies for Atlas, as computed by doKinematics.

One caveat: it doesn't work for floating joints as they are currently implemented. If you parameterize the velocity across a floating joint simply as the twist across the joint in body frame, the motion subspace is simply identity. Instead, if you use yawd/pitchd/rolld or quatd for rotation, it's going to be configuration dependent. I can incorporate that too, but maybe I shouldn't bother if we're going to switch to using twist as the parameterization of velocity across a floating joint.

- Twan

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7993 c9849af7-e679-4ec6-a44e-fc146a885bd3
first pass at proper wrapper method for quadratic programs (and stub for polynomial optimization)

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7994 c9849af7-e679-4ec6-a44e-fc146a885bd3
finished first pass at quadraticProgram wrapper.  leaves much to be desired.

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7995 c9849af7-e679-4ec6-a44e-fc146a885bd3
quickly populated snopt version of polynomialOptimization and sixhumpcamel example.  needs testing.

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/trunk@7996 c9849af7-e679-4ec6-a44e-fc146a885bd3
delete all the deprecated constructPtrXXXConstraintmex and updatePtrXXXConstraintmex

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/branches/hongkaidev@7987 c9849af7-e679-4ec6-a44e-fc146a885bd3
Now the compilation error is gone. I have linking problem to the instantiated inverseKinBackend functions

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/branches/hongkaidev@7989 c9849af7-e679-4ec6-a44e-fc146a885bd3
completed inverseKinBackend.cpp. Still get linking error, but no compilation error

git-svn-id: https://svn.csail.mit.edu/locomotion/robotlib/branches/hongkaidev@7990 c9849af7-e679-4ec6-a44e-fc146a885bd3