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

Backport support for multiple visuals to Kinetic #30

Open
gerkey opened this issue May 17, 2018 · 2 comments
Open

Backport support for multiple visuals to Kinetic #30

gerkey opened this issue May 17, 2018 · 2 comments

Comments

@gerkey
Copy link
Contributor

gerkey commented May 17, 2018

In Kinetic (and probably Indigo), if you define multiple visual tags within a link tag, I get a warning like this:

Scalar element defined multiple times: visual

That warning goes away if I pull urdf_parser_py from source and use the melodic_devel branch. I'm not sure how hard it would be, but it would be nice if the changes that squashed that warning could be cherry-picked back and released into Kinetic.

It looks like the docs were updated to allow multiple visuals in May 2013:

http://wiki.ros.org/action/info/urdf/XML/link?action=diff&rev2=59&rev1=58

@clalancette
Copy link
Contributor

clalancette commented May 18, 2018

I suspect that the relatively recent work in eaea61f, 9fb239b, 5486300, and 4a4451f are why this works in Melodic. We ended up branching off into melodic-devel for these changes (and some others) because we were worried about the impact to downstream users. In particular:

  1. We don't have a huge amount of tests for this package
  2. It is Python, so it is hard to tell exactly what downstream users are accessing in the internals of the package

While technically doing the backport wouldn't be hard, I'd be concerned about the impact to Kinetic (and especially Indigo) users because of those points.

One thing we could consider doing here is waiting 6 months or so to see if Melodic downstream users complain about the API changes that we've made. If we don't hear very much, we could then more seriously consider backporting. What do you think of that proposal?

@gerkey
Copy link
Contributor Author

gerkey commented May 18, 2018

That sounds like a fine plan. And if there remains a concern about the risk of backporting the changes, I'd just leave things as they are. It's not critical.

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

No branches or pull requests

2 participants