D435 testing/tabletop_plane GLEW error

[pv33]

@acmiyaguchi Have you seen this error before when using the mayavi package? Output to command window after running tabletop_plane and hitting "c":

Got the fitted plane from the PCA. The three variance ratios are:[9.2119056e-01 7.8550151e-02 2.5928947e-04]

2023-05-18 11:33:28.013 ( 7.428s) [ F7463740]vtkOpenGLRenderWindow.c:511 ERR| vtkXOpenGLRenderWindow (0x8f2d610): GLEW could not be initialized: Missing GL version

I googled but nothing popped out. Maybe I did not pip install something and the workstation defaults are wrong. For example, the workstation has vtk7, GLEW 2.1.0, OpenGL 1.3.2. Not sure what the dependencies are since I don't know mayavi.

It is not entirely essential, but without it, the script does not output anything useful. Can't confirm functionality and see outcomes relative to measurements. Thanks - PAV.

[acmiyaguchi]

I haven't seen this issue before; I can try to reproduce the issues you're seeing later this evening if you can provide me a short snippet of code to reproduce the issue.

I looked around and https://github.com/openai/mujoco-py/issues/268 might be a relevant solution, which involves preloading a shared library by running export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGLEW.so before running the script.

[pv33]

That doesn't work. Saw it too. The first 20-30 google hits returned nothing of value. I usually go deep about 2-3 pages of hits, so the chances of you finding something I didn't see already are slim.

The best would be to get your setup starting with the versions of installed packages listed in the issue starting message. Let's see if they align. The current vtk is vtk9 I think. Maybe that is what you use? Or there may be nvidia specific problems that require an upgrade of the drivers. That was not noted above, but the nvidia installation provides OpenGL and Mesa libraries custom to nvidia. Let me know what driver version you have or if you don't have nvidia.

Usually these problems are package related on the nvidia side. But who knows.

[acmiyaguchi]

I did most of the work here on bluestreak iirc, but it's been a while so it could have been one of the other PC's. Just to verify, you're running the script under camera/d435/testing/tabletop_plane.py via python -m camera.d435.testing.tabletop_plane?

[pv33]

Kinda yes. I go directly to the directory then type python tabletop_plane.py.

The other two testing scripts in that directory work (height.py and aruco_cali.py) as they don't rely on mayavi. Did not test usage.py but pretty sure it will work.

[pv33]

Next time I work on this part of the project, I'll check out bluestreak. What login did you use just in case that matters due to pip installed packages?

[acmiyaguchi]

I used the vipteam login.

There are issues with using pptk outside of python 3.7, which is why I opted for mayavi for newer machines. I can optionally add the package back if that resolves issues going forward for an older machine e.g. ubuntu 16.04. You can also use the 1.1.0 tag/package (https://github.com/ivapylibs/camera/releases/tag/1.1.0) which should work as expected. The directory structure is a bit different though, which is why there was a major version bump on those newer changes.

[acmiyaguchi]

So this is a dependency issue on VTK based on the error message (https://github.com/Kitware/VTK/blob/master/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx), which means this just wont run on old systems (with the exception of maybe pinning mayavi to older versions(?)).

For context, I can run this fine on ubuntu 20.04 (with a slightly newer version of opengl to fix some gazebo rendering issues in wsl2):

$ glxinfo | grep "OpenGL version"
OpenGL version string: 4.2 (Compatibility Profile) Mesa 23.1.0 - kisak-mesa PPA

This probably also works fine on bluestreak, which is why I didn't run into this earlier. I've added a matplotlib fallback which should unblock any of the workflows that are using the plotting utility.

[pv33]

@acmiyaguchi Thanks. I am going to pause this for a bit and work on a better API for the realsense. The code is quite ugly and lacks the flexibility needed to optimize usage and to permit consistent setup from sitting to sitting. Also going to improve ROS integration.

Coding into runner2.py which will eventually be moved to runner.py or possibly renamed to something else. I am not sure about the name "runner" and have generally not liked it. Wonder if there is some convention leading to this name.