Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency with axis parsing in SdfParser #370

Closed
mxgrey opened this issue Mar 29, 2015 · 8 comments
Closed

Inconsistency with axis parsing in SdfParser #370

mxgrey opened this issue Mar 29, 2015 · 8 comments
Assignees
Labels
priority: low no timeline yet
Milestone

Comments

@mxgrey
Copy link
Member

mxgrey commented Mar 29, 2015

I've noticed that readRevoluteJoint, readPrismaticJoint, readScrewJoint, and readUniversalJoint are all parsing "axis" elements, but only readRevoluteJoint is checking for a "use_parent_model_frame" element. This inconsistency seems very suspicious to me.

Is that tag something unique to Revolute Joints? I can't imagine why it would be. I'm going to make a function for parsing axis elements and use that function for each joint parser in order to have better consistency among them. Stop me if there are some irregularities I should know about.

@mxgrey mxgrey self-assigned this Mar 29, 2015
@jslee02
Copy link
Member

jslee02 commented Mar 29, 2015

It should be applied to every joint type. I added it for RevoluteJoint for quick test and forgot to add it for other joint types.

@mxgrey
Copy link
Member Author

mxgrey commented Mar 29, 2015

Okay, I'm making a separate function for axis parsing and then I'll have it be used in every joint type. That should help code complexity and maintainability.

@jslee02
Copy link
Member

jslee02 commented Mar 29, 2015

Sounds good!

@mxgrey
Copy link
Member Author

mxgrey commented Mar 29, 2015

On a somewhat related note: is there a particular motive for having the SoftSdfParser separate from the SdfParser? Is the format for the soft SDFs any different than some new element types being introduced to SDF? Are they being kept separate only because the soft SDF is experimental?

@jslee02
Copy link
Member

jslee02 commented Mar 29, 2015

In the first place, DART had separate classes and parsers to support soft body dynamics such as SoftBodyNode, SoftSkeleton, SoftWorld, SoftSkelParser, and SoftSdfParser. Later we decided to merge them into the original classes except for SoftBodyNode, and SoftSdfParser is just left to be merged to SdfParser which hasn't been done yet.

SDF already has new element types to support DART's soft body node. However, SoftSdfParser and SDF has little bit different elements, and the places in the structure are also different. So we need to adapt to SDF's one.

@mxgrey
Copy link
Member Author

mxgrey commented Mar 29, 2015

I've found a lot of copy/pasting in the SoftSdfParser implementation, so I've cut that down heavily with a little bit of templating and std::function. Now SoftSdfParser will be a much simpler extension of SdfParser.

I'm going to leave the task of updating to the latest SDF format to someone else, since I don't use soft bodies myself.

@jslee02
Copy link
Member

jslee02 commented Mar 29, 2015

Sure. I created an issue #371 for it.

@mxgrey
Copy link
Member Author

mxgrey commented Apr 9, 2015

I think this issue can be closed, because it has been addressed in pull request #369 which is just pending cleanup and review at this point.

@mxgrey mxgrey closed this as completed Apr 9, 2015
@jslee02 jslee02 added this to the Release DART 5.0 milestone May 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: low no timeline yet
Projects
None yet
Development

No branches or pull requests

2 participants