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

Add ModelExporter class and add preliminary support for exporting URDF from iDynTree::Model #554

Merged
merged 2 commits into from
Aug 23, 2019

Conversation

traversaro
Copy link
Member

@traversaro traversaro commented Aug 14, 2019

Add iDynTree::ModelExporter class and related tests.

Currently the only format supported for export is the URDF format.

Currently the model exporter only exports a subset of the features supported in iDynTree::Model. In particular, the following features are not supported:

  • Additional frames
  • Visual and Collision Geometries
  • Sensors
  • Joint limits, friction parameters
  • Automatically change link frames location for link whose origin does not lay on the rotation/translation axis of the parent joint, as requested by URDF
  • Wrapping the ModelExporter in bindings

The PR is composed by the following two commits:

  • 5982124 : Add fpconv as a MIT-licensed vendored dependency, to support double - shortest string exact conversion, that is currently not supported in the STL. This will be removed as soon as we can depend on C++17's std::to_chars
  • 047ef63 : Add ModelExporter class, support for exporting URDF, and tests.

My idea is to implement most of the missing features before 0.12 release, but as the limitations are currently documented, I think it make sense to first review this initial PR, and then the other features can be added in future PRs.

This PR is based on the old closed PR #382 .

This dependency is necessary to convert a double to its shortest string exact
representation. It can be probably removed as soon as std::to_chars is widely
available.
*
* @warning This function does not support exporting sensor or solid shapes at the moment.
*
* @param[in] options the URDFParserOptions struct of options passed to the parser
Copy link
Contributor

@prashanthr05 prashanthr05 Aug 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be great to document also the output and default parameters here. Also, if we should specify a relative path or an absolute path of the urdf file. These details are not clear.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the default options, the user is referred to the iDynTree::ModelExportOptions, that contains docs related to the available and the default options. I will make it clear in the commit to address reviews, let me know if it is enough.

xmlNodePtr child_xml = xmlNewChild(joint_xml, NULL, BAD_CAST "child", NULL);
xmlNewProp(child_xml, BAD_CAST "link", BAD_CAST model.getLinkName(childLink->getIndex()).c_str());

// TODO(traversaro) : handle joint limits and friction
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be moved also in the documentation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree this is not mentioned in the description of the pr

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is still pending

xmlNewProp(robot, BAD_CAST "name", BAD_CAST "iDynTreeURDFModelExportModelName");
xmlDocSetRootElement(urdf_xml, robot);

// TODO(traversaro) : We are assuming that the model has no loops,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This must be mentioned in the documentation, explicitly. Since I notice there are users of iDynTree in the cable robots or parallel mechanisms community as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be in the main readme of idyntree not only in this pr
I thought it was there but I could not find a mention to it now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related issue: #555 .

Copy link
Contributor

@fjandrad fjandrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small doubt about the unit test not checking for the sensors

@prashanthr05
Copy link
Contributor

I think it will be helpful if we add an explicit print to console statement in the URDFStringFromModel or URDFFromModel functions about the elements that the user should not expect in the generated urdf file. Like the ones described in the PR. One step forward in avoiding any possible errors while using the generated urdf.

@traversaro
Copy link
Member Author

I think it will be helpful if we add an explicit print to console statement in the URDFStringFromModel or URDFFromModel functions about the elements that the user should not expect in the generated urdf file. Like the ones described in the PR. One step forward in avoiding any possible errors while using the generated urdf.

I totally agree with this suggestion, but I expect to implement most of those features before the 0.12 release, so I would prefer to avoid overthinking how to report this problems to the user, as eventually we will need to remove them. If for the 0.12 release we still miss some features, then I would agree to add those error messages.

@traversaro
Copy link
Member Author

Reviews addressed in 15f4848 .

Copy link
Contributor

@fjandrad fjandrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small variable name to check and some documentation concerns

ok = ok && exportTransform(Transform(Rotation::Identity(), inertia.getCenterOfMass()), inertial);

xmlNodePtr inertia_xml = xmlNewChild(inertial, NULL, BAD_CAST "inertia", NULL);
RotationalInertiaRaw rotInertia = i.getRotationalInertiaWrtCenterOfMass();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this one was also meant to be inertia and not i

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That happens when you modify the code and you do not try to recompile it. : )
Thanks for the check.

xmlNewProp(robot, BAD_CAST "name", BAD_CAST "iDynTreeURDFModelExportModelName");
xmlDocSetRootElement(urdf_xml, robot);

// TODO(traversaro) : We are assuming that the model has no loops,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be in the main readme of idyntree not only in this pr
I thought it was there but I could not find a mention to it now.

xmlNodePtr child_xml = xmlNewChild(joint_xml, NULL, BAD_CAST "child", NULL);
xmlNewProp(child_xml, BAD_CAST "link", BAD_CAST model.getLinkName(childLink->getIndex()).c_str());

// TODO(traversaro) : handle joint limits and friction
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is still pending

@traversaro
Copy link
Member Author

traversaro commented Aug 19, 2019

@fjandrad I am not sure why I cannot directly respond to your comments, anyhow I reply to them here.

I think this should be in the main readme of idyntree not only in this pr
I thought it was there but I could not find a mention to it now.

It make sense, I opened a new issue for this in #555 .

I think this is still pending

I already added it in 15f4848#diff-05b37777f3462332b9cce4040d3f16deR69 for the main user facing documentation, and I added it in the specific function private docs in ba04aaa .

As far as I know all your comments should be addressed.

@traversaro
Copy link
Member Author

Friendly ping @prashanthr05 @fjandrad .

@traversaro
Copy link
Member Author

A legit problem in the build system on macOS was detected by Travis in https://travis-ci.org/robotology/idyntree/jobs/573683257, and it should be fixed by aaf1dec .

@traversaro
Copy link
Member Author

Friend ping @fjandrad

@traversaro
Copy link
Member Author

Thannks for the reviews @fjandrad and @prashanthr05 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants