Giter VIP home page Giter VIP logo

Comments (22)

moorepants avatar moorepants commented on August 29, 2024

@chrisdembia thought's on this? Should I'll look up what Yeadon calls it.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

I just looked quickly; he mentions "thigh flexion" in paper iii. The documentation should say flexion. Maybe I had just been copying what I had done for the arms. I vote we change the documentation to say flexion.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

Yeah, it looks like he uses "flexion" at the beginning of appendix 1 in the ii paper. I haven't seen any mention of "elevation" in papers i or ii for any joints.

Let's just change the docs to flexion.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

K I'll do that.

On Fri, Dec 13, 2013 at 7:52 AM, Jason Moore [email protected]:

Yeah, it looks like he uses "flexion" at the beginning of appendix 1 in
the ii paper. I haven't seen any mention of "elevation" in papers i or ii
for any joints.

Let's just change the docs to flexion.


Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-30519277
.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

Oh nevermind. Thanks!

On Fri, Dec 13, 2013 at 8:30 AM, Christopher Dembia [email protected]:

K I'll do that.

On Fri, Dec 13, 2013 at 7:52 AM, Jason Moore [email protected]:

Yeah, it looks like he uses "flexion" at the beginning of appendix 1 in
the ii paper. I haven't seen any mention of "elevation" in papers i or ii
for any joints.

Let's just change the docs to flexion.


Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-30519277
.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

DARNIT DARNIT. Okay the current issue at commit e681fdd is that P[JK]1flexion is in fact extension. The easiest way to see this is in the GUI. Everything else is consistent. That is, P[JK]1extension no longer appears anywhere.

There are two fixes:

  1. Put a negative in front of self.CFG['PJ1flexion'] in the assignment of J1RotMat, etc.
  2. Change all instances of P[JK]1flexion to P[JK]1extension.

Reason for 1: Yeadon mentions "flexion" in paper iii.
Reason for 2: Conversation in issue #41 that discourages the use of negations in the rotations.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

So is this a name issue or rotation definition issue? I thought we fixed it such that all rotations are now body fixed XYZ rotations.

What do you mean that P[JK]1flexion is in fact extension?

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

I just opened the GUI from master and it seems to work correctly with regards to the thigh angles.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

Ok, I get it now. You are worried about the sense (positive/negative) for the definitions of flexion and extenstion (http://en.wikipedia.org/wiki/Anatomical_terminology#Flexion_and_extension).

So if you choose body fixed rotations the signs of the angles are fixed. Then you want to assign meaningful anotomic names to each of the angles. And the terms "flexion" and "extension have to do with signs of rotations. I would suggest choosing the names that match the rotation as defined rather than adding negative signs everywhere, because of the mathematical confusion.

If that is the case we will may have to revisit the names for the elbow angles too, as they are called flexion but negative angles equal positive flexion.

Or you can name things like A1A2flexion-extension, but that sucks.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

Are you considering that the green arrow points posteriorly? positive
values for PJ1flexion put the leg into extension.

On Tue, Dec 17, 2013 at 1:53 PM, Jason Moore [email protected]:

I just opened the GUI from master and it seems to work correctly with
regards to the thigh angles.


Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-30795102
.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

Damn, we missed this when I made all those changes to make everything body fixed XYZ rotations.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

On my new work computer the gui is so smooth.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

haha awesome. It also seems that elevation should maybe be switched,
thought it seems this would more aptly be called flexion/extension, but
Yeadon uses elevation in his first paper.

What do you think?

On Tue, Dec 17, 2013 at 2:04 PM, Jason Moore [email protected]:

On my new work computer the gui is so smooth.


Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-30795990
.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

I don't want to add negative signs anywhere because it is much better to just say "all rotation are body fixed XYZ (Euler angles)." And I spent a lot of time making sure that was consistent. I think this matches Yeadon's definition so the angles are all consistent. Now whether Yeadon uses the correct names for these angles is maybe is less concrete. He doesn't write them down much nor is he consistent.

I never noticed the incorrect names of these, because I've never really internalized what flexion and extension mean. I think of it more like "knee angle", "shoulder angles", etc.

The abduction, flexion, elevation, etc paradigm doesn't really seem to fit well with euler angle definitions. For example, If I abduct my shoulder from a starting position of hanging down, that is abduction (lifting out to the side). But if I first elevate and then rotate about the new abduction axis, and rotate postively, then I will rotate my arms back into the hanging down position, which isn't abduction. The anatomical names do not seem to fit with Euler definitions.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

Okay yea so if a mechanical engineer sees the code they won't think twice, but a person coming from anatomy, etc. may be confused. Especially if they don't visualize.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

Conundrum. Would it be bad to just change the angle names to match? If we do, we may need a dictionary that maps new and old names so that is is backwards compatible.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

And if you are just typing code like:

flexion = 5.0

You would expect to get a positive flexion angle.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

Oh mann I don't like the added complication of using multiple names. That is potentially even MORE confusing. I just realized what we do for OpenSim is we call the DOF at the knee "knee angle" and the DOF at the ankle "ankle angle". This would work, but when I was first learning, I had to keep checking the sense of the DOF. It would be awesome if we could save people that step. It's especially confusing in Yeadon b/c we show these arrows/vectors in the configuration figure that denote sense.

The IDEAL for me would be to change the names to denote the correct sense (PJ1extension), and forget about backwards compatibility.

I'd then say a compromise would be to use "PJ1angle", but even if we do this we need to create the dict for backwards compatibility, so we may as well change the name to PJ1extension.

And I agree, that the negative signs are very confusing for the implementors, and we should avoid these as well.

So I really think the best thing would be to forget about backwards compatibility. The only other option seems to be to choose a solution that involves only editing the figure.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

Implementing backwards compatibility isn't technically a big deal. If we don't do that we should release Yeadon 2.0. But I think we can just leave the old names with a warning. I've already implemented most of it with the mispelling changes we had. It will just say "Use the correct name from now on." This is nice because code that depends on Yeadon will not break on upgrade. But we probably don't have any users, so maybe this makes no difference.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

I think it wouldn't be too difficult to implement the backwards capability.
But, the purpose of the change would be to remove something that's unclear.
I think that the backwards compatibility would create an interface that is
potentially even more unclear. But maybe I'm wrong about the decrease in
clarity.

On Thu, Dec 26, 2013 at 5:19 PM, Jason Moore [email protected]:

Implementing backwards compatibility isn't technically a big deal. If we
don't do that we should release Yeadon 2.0. But I think we can just leave
the old names with a warning. I've already implemented most of it with the
mispelling changes we had. It will just say "Use the correct name from now
on." This is nice because code that depends on Yeadon will not break on
upgrade. But we probably don't have any users, so maybe this makes no
difference.


Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-31242726
.

from yeadon.

moorepants avatar moorepants commented on August 29, 2024

The backwards compatibility wouldn't be documented, per se. From a new user's perspective, they would only see the new labels so no confusion for them. But for old users it would just ensure that old code and old input files still worked. It is really annoying and a pain when you pip install -U <something> and your code that depends on it breaks. Theoretically one could use a mix of old and new labels but most sane people would just switch to the new way after they get the deprecation warnings. This would just ensure that upgrades go smooth behind the scenes.

from yeadon.

chrisdembia avatar chrisdembia commented on August 29, 2024

Fixed by #87

from yeadon.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.