Backport support for multiple visuals to Kinetic

[gerkey]

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]

I suspect that the relatively recent work in https://github.com/ros/urdf_parser_py/commit/eaea61f89f9e7380ab1ff5715d4b41d105cfbb73, https://github.com/ros/urdf_parser_py/commit/9fb239b47cfbaa734253081b259c940935d56634, https://github.com/ros/urdf_parser_py/commit/548630013258ba721ce921aa2344c81574b427d2, and https://github.com/ros/urdf_parser_py/commit/4a4451fb8428fe7d4c01fd0d0fd04d27a850c246 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]

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.