Comments (22)
@chrisdembia thought's on this? Should I'll look up what Yeadon calls it.
from yeadon.
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.
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.
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.
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.
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:
- Put a negative in front of
self.CFG['PJ1flexion']
in the assignment ofJ1RotMat
, etc. - 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.
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.
I just opened the GUI from master and it seems to work correctly with regards to the thigh angles.
from yeadon.
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.
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.
Damn, we missed this when I made all those changes to make everything body fixed XYZ rotations.
from yeadon.
On my new work computer the gui is so smooth.
from yeadon.
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.
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.
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.
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.
And if you are just typing code like:
flexion = 5.0
You would expect to get a positive flexion angle.
from yeadon.
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.
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.
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.
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.
Fixed by #87
from yeadon.
Related Issues (20)
- Many test failures HOT 2
- Link to measurement guide
- Get rid of numpy.matrix
- Load/Save for configurations in GUI
- Make a 1.2.0 release. HOT 4
- Add a "this is how to cite us" section in the README/DOCS once paper is published.
- Error installing in a Conda env HOT 1
- Line 22 of bicycle example HOT 1
- pip installing yeadon requires pyyaml to be preinstalled HOT 3
- somersalt -> somersault.
- Update readthedocs to 1.2.1
- Rebuild and host the conda packages HOT 1
- Lots of test failures on Travis HOT 1
- New release for py3 support HOT 8
- 1.2.1 PyPi source download is incorrect HOT 2
- Use entry points instead of scripts in setup.py. HOT 1
- Dash VTK might make it relatively easy to make a yeadon web app
- Input joint positions instead of joint angles HOT 2
- rel_combine_inertia HOT 1
- Human figure does not show up in the app HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yeadon.