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

urdf_parser_py.urdf not working on ros melodic #58

Open
mmoerdijk opened this issue Apr 22, 2020 · 1 comment
Open

urdf_parser_py.urdf not working on ros melodic #58

mmoerdijk opened this issue Apr 22, 2020 · 1 comment

Comments

@mmoerdijk
Copy link

I noticed that the xacro command under melodic adds the encoding attribute to the xml tag of the generated urdf file. This gives problems with the underlying lxml parser. That complaints about:

ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.

Here by a minimal example to reproduce this error under ros melodic:

import roslib; roslib.load_manifest('urdfdom_py')
import rospy

# Import the module

from urdf_parser_py.urdf import URDF

robot = URDF.from_xml_string("<?xml version=\"1.0\" encoding=\"utf-8\"?><robot name='myrobot'></robot></xml>")

The version without the encoding attribute works correctly

import roslib; roslib.load_manifest('urdfdom_py')
import rospy

# Import the module

from urdf_parser_py.urdf import URDF

robot = URDF.from_xml_string("<?xml version=\"1.0\" "?><robot name='myrobot'></robot></xml>")

I noticed this when using the URDF.from_parameter_server() command that now no longer works (It still works with ros kinetic)

A simple solution would be to remove the encoding tag from the parameter string before passing it to the parser. But im not sure if this is the way to go. If you agree with this solution i can open a PR to fix this.

@clalancette
Copy link
Contributor

Hm, yeah, that's a problem. @sloretz it looks like we have a systems type problem here in that xacro and urdf_parser_py are no longer working together nicely. I don't have a great way to solve this; should we think about reverting 22f3a60 ?

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