problem getting CarSim to run on Win64

[sherm1]

I am making my first attempt to build Drake, on Windows 10 VS 2015 Win64 (source from master). I don't have Matlab so am trying to test by running the Cars example. I'm using a binary version of the visualizer provided by @RussTedrake. I ran and got the screenshot below. But then the shell window for the visualizer started spewing messages like this:

But the visualizer’s shell window started continuously spitting out a bunch of errors that look like:
KeyError: u'body'
Traceback (most recent call last):
File "C:/Users/Sherm/Documents/GitHub/RobotLocomotion/director-win32-binary/director-binary/lib/python2.7/dist-packages\ddapp\lcmUtils.py", line 116, in handleMessage
callback(msg)
File "C:\Users\Sherm\Documents\GitHub\RobotLocomotion\director-win32-binary\director-binary\lib\python2.7\dist-packages\ddapp\drakevisualizer.py", line 301, in onViewerDraw
link = self.getLink(robotNum, linkName)
File "C:\Users\Sherm\Documents\GitHub\RobotLocomotion\director-win32-binary\director-binary\lib\python2.7\dist-packages\ddapp\drakevisualizer.py", line 279, in getLink
return self.robots[robotNum][linkName]

Does this provide any information about where I might be going wrong?

Sherm

[RussTedrake]

Ah — just realized that the car body is in fact the only actual mesh. I bet it’s the relative file path issue. You have to launch the director from the right directory: https://github.com/RobotLocomotion/drake/issues/1636 (although there is a pull request started which will fix it) And of course if you’re launching director from the windows gui, this will not happen automatically. Doh. Sorry I forgot that.

[sherm1]

Changing to absolute paths and launching the visualizer in the local directory didn't appear to fix anything. However, I was able to capture the first visualizer traceback:

Sorry if that is unreadable -- the last line says Unknown file extension in readPolyData: ./prius.dae.

[sherm1]

Removing the <visual> section containing the mesh file reference from prius.urdf got rid of the visualizer message flurry. World now shows; car doesn't. But that's progress, I think!

[RussTedrake]

I think it's still not finding the file. What if, instead of commenting out the visual element, you made a local edit which put the global path to the file in the urdf? That might be a useful debugging step.

[sherm1]

What if, instead of commenting out the visual element, you made a local edit which put the global path to the file in the urdf?

I did try that first but the code prepends ./ or ./prius to the full path in that case making it malformed.

[liangfok]

I just encountered the same "Unknown file extension in readPolyData" error on an Ubuntu Linux machine:

$ ../../../build/bin/drake-visualizer
Traceback (most recent call last):
  File "/home/liang/dev/drake/build/lib/python2.7/dist-packages/director/lcmUtils.py", line 116, in handleMessage
    callback(msg)
  File "/home/liang/dev/drake/build/lib/python2.7/dist-packages/director/drakevisualizer.py", line 256, in onViewerLoadRobot
    l = Link(link)
  File "/home/liang/dev/drake/build/lib/python2.7/dist-packages/director/drakevisualizer.py", line 209, in __init__
    self.geometry.extend(Geometry.createGeometry(link.name + ' geometry data', g, self.transform))
  File "/home/liang/dev/drake/build/lib/python2.7/dist-packages/director/drakevisualizer.py", line 178, in createGeometry
    polyDataList = Geometry.createPolyDataForGeometry(geom)
  File "/home/liang/dev/drake/build/lib/python2.7/dist-packages/director/drakevisualizer.py", line 168, in createPolyDataForGeometry
    polyDataList = Geometry.loadPolyDataMeshes(geom)
  File "/home/liang/dev/drake/build/lib/python2.7/dist-packages/director/drakevisualizer.py", line 149, in loadPolyDataMeshes
    polyDataList = [ioUtils.readPolyData(filename)]
  File "/home/liang/dev/drake/build/lib/python2.7/dist-packages/director/ioUtils.py", line 23, in readPolyData
    raise Exception('Unknown file extension in readPolyData: %s' % filename)
Exception: Unknown file extension in readPolyData: 
Error locating link name: body
Error locating link name: left_tie_rod_arm
Error locating link name: left_hub
Error locating link name: left_wheel
Error locating link name: rear_axle
Error locating link name: left_wheel_rear
Error locating link name: right_tie_rod_arm
Error locating link name: right_hub
Error locating link name: right_wheel
Error locating link name: right_wheel_rear
Error locating link name: tie_rod

Looking in Director's ioUtils.py, line 9, I see that Director does not support DAE files:

    ext = os.path.splitext(filename)[1].lower()

    readers = {
            '.vtp' : vtk.vtkXMLPolyDataReader,
            '.vtk' : vtk.vtkPolyDataReader,
            '.ply' : vtk.vtkPLYReader,
            '.obj' : vtk.vtkOBJReader,
            '.stl' : vtk.vtkSTLReader,
              }

    try:
        readers['.pcd'] = vtk.vtkPCDReader
    except AttributeError:
        pass

    if ext not in readers:
        raise Exception('Unknown file extension in readPolyData: %s' % filename)

From the code fragment above, ioUtils.py supports .obj files. There is a prius.obj file in Drake's repo. I thus modified my prius.sdf file to load the prius.obj mesh instead of the prius.dae mesh and it worked.

It remains a mystery to me why prius.urdf can load the DAE mesh file while prius.sdf cannot.

@patmarion, can you provide any insight?

[patmarion]

You shouldn't edit the urdf file to insert absolute filenames for meshes, that won't work, because drake will always treat the filename as being relative to the urdf. Instead, you should change the urdf command line argument to be the absolute path to the urdf file.

The visualizer does not have support for .dae files. When a urdf file specifies a .dae file, the visualizer searches for a files with supported extensions (.obj, for example) in the same directory as the .dae file. If no file exists, or the path to the .dae file is incorrect, then no other file is found, so the visualizer attempts to load the .dae file and fails.

I will fix the visualizer to provide a more helpful error message for the case when the path to the .dae file is incorrect, in which case, the error shouldn't be ".dae extension not supported" it should be, ".dae file does not exist, please check whether the path is correct"

[sherm1]

Thanks, Liang, Pat, and Russ. I got this to build and run by

• installing the GNU Tools "patch" command, which ironically then has to be patched like this. (This seemed necessary to get past the Bullet installation.)
• changing prius.dae to prius.obj in the urdf
• specifying absolute path names for the urdf and sdf arguments to carSimLCM

[RussTedrake]

give your recent experience, would love to hear your thoughts on this: https://github.com/RobotLocomotion/bullet-pod/pull/10

[patmarion]

I am testing on Ubuntu, and I cannot reproduce the error. Are you guys testing with a different branch? The only requirement is specifying the path to the urdf or sdf file using absolute filename. I do not have to edit/modify the contents of .urdf or .sdf to change .dae to .obj. As long as the absolute path is used, then Director does the right thing.

The issue of relative/absolute path is discussed here:

https://github.com/RobotLocomotion/drake/issues/1636

An unmerged pull request to resolve the issue is here:

https://github.com/RobotLocomotion/drake/pull/1736

[sherm1]

Pat, I'm on Windows and building from a freshly-updated drake master branch. I just now verified that reverting prius.urdf to use prius.dae fails (I get just the chassis displayed then the visualizer goes nuts with error message), while using prius.obj works fine giving me a prius body and a functional simulation.

[patmarion]

Ok, thanks for the info. I think the difference could be that Windows version of the visualizer is out dated and does not have the extra logic that searches for a .obj file to use in place of the .dae file.

We have an open issue to get a nightly build of Director for Windows:

https://github.com/RobotLocomotion/drake/issues/1786

[david-german-tri]

Closed as redundant with #1786.