Matt ayman frames

Merge in branch from Hackathon to create new ModelComponents: Frame, BodyFrame, FixedFrame and Station. The functionality is tested in a separate test case testFrames and in testComponents but is not incorporated into any Models or computations yet. Please take a look at the headers and give us feedback if you plan to use this functionality. The plan is to use Frames to attach geometry, joints, wrapping etc. and to make Markers utilize Stations.
Hi, Matt. That’s why these things create so much confusion! Everything you said is correct, but it is based on viewing the transform through the filter of a particular operation using it, one of many possibilities. Other operations, say composition or reexpressing a tensor, would lead to different descriptions. An alternate way to describe these objects is by how they are constructed, in which case one of the two frames is the “measured in”/”measured from” frame. By Simbody convention that is the frame on the left. So the object X_AB is constructed by expressing B’s axes in A’s frame, measuring B’s origin from A’s origin and then laying out the four resulting vectors as columns. 

 

There are no English words that describe any of this unambiguously. Relative terms like “from” and “to” get interpreted from where you’re standing at the time. Consistent conventions and good notation work much better. I would give the method a noncommittal name like getTransform() or getGroundTransform() and then show precisely in the doxygen documentation the quantity being returned, e.g. X_GB. Then we only have to teach people to line up the frame names properly.

 

For internal use where you don’t have to worry about scaring users, I would recommend cutting out the English fluff altogether and going with getX_GB() or whatever.

 

Sherm

 

From: Matt DeMers [mailto:notifications@github.com] 
Sent: Wednesday, August 06, 2014 11:37 AM
To: opensim-org/opensim-core
Cc: Michael Sherman
Subject: Re: [opensim-core] Matt ayman frames (#145)

 

In OpenSim/Simulation/Model/BodyFrame.h:

> +    // CONSTRUCTION
> +    //--------------------------------------------------------------------------
> +    /** default contructor*/
> +    BodyFrame();
> +
> +    /** Convenience constructor */ 
> +    BodyFrame(const Body& body);
> +    
> +
> +    // use compiler generated destructor, copy constructor and assignment operator
> +
> +    /** Access Properties of the Body */
> +
> +    /** Spatial Operations for Frames*/
> +    virtual const SimTK::Transform& getTransform() const;
> +    virtual const SimTK::Transform calcTransformToGround(const SimTK::State &state) const;

@sherm1 <https://github.com/sherm1>  wait what? Isn't this the wrong sense? This is the exact opposite of the comments and convention I've seen in Simbody say. These transforms are left operators, correct? X_GA converts vectors expressed in A to vectors expressed in Ground.

Inside calcTransformToGround, I directly call simbody's method getBodyTransoform(). Its comment states. "Extract from the state cache the already-calculated spatial configuration 
X_GB of body B's body frame, measured with respect to the Ground frame and 
expressed in the Ground frame." This is the measure of B's translation and orientation in Ground, which when used as a left transform operator should be transforming any right-multiplied vector "From" the B basis "To" the ground basis. like this. 

vec_in_Ground = Ground_X_B * vec_in_B

In Ground_X_B contains the position of B's origin in Ground, and a rotation matrix in which the columns 1,2,3 are the unit vectors of Bx,By,Bz. 

Unless I'm misunderstanding the comment, "To" ground is correct because the transfrom converts vectors from the B basis "To" the ground basis. At least, this is how we always termed transforms in Scott, Paul, and Oussama's classes.

—
Reply to this email directly or view it on GitHub <https://github.com/opensim-org/opensim-core/pull/145/files#r15893771> .  <https://github.com/notifications/beacon/4088016__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyMjk2OTQxNCwiZGF0YSI6eyJpZCI6Mzg5MDI4NzV9fQ==--1f626c7fac4aca61e334738e4261707f84af2614.gif>