Allow (simulated) display to be used with ci builds

[scottpaulin]

This now allows a display to be used in ci testing. I tested this with the moveit_ros repo, the mesh_filter tests are no longer disabled meaning there is a display detected.

I found the xvfb instructions on someone else's repository (lost the link) after the instructions from travis here didn't work. As I understand it xvfb is used to simulate a display on virtual frame buffer 99. I think 99 is used because it is less likely to be used for something else (see here).

The change to travis.sh allows the display simulated by xvfb to be used in Docker. This was implemented following the wiki instructions here (thanks for the link @davetcoleman !).

[davetcoleman]

I added Travis to this repo so moveit_ci can test moveit_ci - can you rebase your PR with latest commits before I merge this? Thanks

[scottpaulin]

I think this is now rebased (I haven't done this before). Please let me know if it didn't work.

[davetcoleman]

Can you add a comment here explaining the gist of what these two lines do?

[davetcoleman]

@scottpaulin you rebased correctly, good job! unfortunately I realized I setup the travis script to test this incorrectly - when it says "All checks have passed" it is not actually testing your modifications but just the master version. Needed 9f3c97a

Could you rebase again against master? My bad. Also don't forget to address my inline comments

[scottpaulin]

I have added comments and cleaned up the Xvfb command. It was specifying a screen resolution, but the default should work fine.

Also rebased.

I just added you as an admin to my fork in case there is a minor change you need to make in the next few days. We just got snow so I will be away skiing (not biking to the field though!).

[davetcoleman]

haha its ski season for you?? even our back country is dried up by now

I'm not sure this PR fixes the desired issue - looking at the Travis build just now I still see

No display, will not configure tests for moveit_ros_perception/mesh_filter

I don't really know, but perhaps this is an unavoidable limitation of a server?

[scottpaulin]

Yip! Southern hemisphere :)

Sorry I broke this in the last commit (too keen to ski), but not in the way you describe. Did you change .travis.yml in moveit_ros to include the changes in the template from moveit_ci/Readme? It should look something like this.

I don't really know, but perhaps this is an unavoidable limitation of a server?

Nah, I made sure it was working before making this PR. Xvfb is specifically for simulating displays on machines without screens. I will test it again when the ci build is passing and leave a comment here, before the Moveit! repo merge if possible.

[davetcoleman]

Did you change .travis.yml in moveit_ros to include the changes in the template from moveit_ci/Readme?

Ha, no I didn't. Can you fix the merge conflict? then I'll test it in the unified repo...

[davetcoleman]

Testing this PR here: https://travis-ci.org/davetcoleman/moveit/builds/150449446

[scottpaulin]

Haha looks like we both had test builds running that resulted in build errors from the mesh_filter unit tests. At least it means that the display has been detected. The 'static const member variables must be constexpr' is a c++11 thing.

I have fixed that build error in my fork which can later be a PR against moveit. The build output is here.

I think there are a few more build errors because Google Test's EXPECT_TRUE explicitly requires a bool argument, but the mesh_filter tests are using it to check for nullptrs. I am happy to fix the build errors, should I raise it as an issue in Moveit?

Sorry about the delay in handling this, I have been sick :(.

[davetcoleman]

Awesome that its working and catching bugs! Now your travis is showing another issue:

[ RUN      ] float_test/MeshFilterTestFloat.float/0
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
freeglut  ERROR:  Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow

[scottpaulin]

Hmm it looks like there might be two problems here 1) OpenGl can't find the graphics hardware drivers and 2) Xvfb possibly does not support the required frame buffer format.

I am trying to solve 1) by installing the mesa drivers (see second answer), the build is here.

When I tested it pre-PR it was timing out (which it does when the screen resolution is set) and I incorrectly thought it was due to the mesh_filter unit tests.

[davetcoleman]

Your build passed but still says "No display, will not configure tests for moveit_ros_perception/mesh_filter"

[scottpaulin]

Installing the mesa drivers got rid of these errors:

[ RUN      ] float_test/MeshFilterTestFloat.float/0
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
freeglut  ERROR:  Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow

Free glut now seems to be having trouble opening the display:
line 3658: freeglut failed to open display ':99.0'
This could be a permissions problem with accessing the X server. I am now trying to relax permissions with xhost+. Suggestions very welcome :)

[davetcoleman]

What a headache! I do not have much experience with X server stuff

[davetcoleman]

Hey @scottpaulin, any progress on fixing this test on Travis?

[scottpaulin]

Unfortunately not. I am out of ideas

[scottpaulin]

I have done plenty of Googling-Stackoverflow on this and am super stuck. Should I just reject this PR and close it?

[davetcoleman]

Perhaps @ruffsl has advice on adding a virtual display/GPU since he's worked extensively with Docker containers.

Maybe we need something like https://github.com/NVIDIA/nvidia-docker

[ruffsl]

The nvidia-docker plugin is relevant if the host has nvidia hardware and drivers.
I have had much luck using OpenGL with docker and nvidia GPUs:
NVIDIA/nvidia-docker#136 (comment)

Does your travis provider use servers with nvidia GPUs? Is the docker engine running within a VM, and does the VM have have access to the PCI passthrough for the GPU? I'm not sure of the shape of the stack of Travis's CI stack. I am yet unsure how you could swap the call to the docker run cli with nvidia-docker run cli in this travis environment.

Last summer I was playing around getting gazebo to work on a headless amazon aws instance with nvidia gpus. I was running gzclient remotely from my local workstation, but I needed the gzserver to have a virtual display so that ogre could render the camera views in simulation, with the GPU acceleration speeding up the render rates. Here is my (perhaps dated, before the nvidia-docker plugin came around) notes on what I did to get it working:
https://github.com/ruffsl/gazebo_docker_demos/blob/master/aws/setup_remote.md

I'd imagine getting the integrated intel graphics to work might be simpler, no need for drivers and plugins the mount devices, just the correct packages. I think someone added some intel info to the wiki i started here:
http://wiki.ros.org/docker/Tutorials/Hardware%20Acceleration#Intel

Perhaps @scpeters or @hugomatic might have some more incite, as I recall they were working around some of these issues more recently with cloud based simulation development.

[scpeters]

We have been using nvidia-docker locally with quite a bit of success, though I haven't used it in a CI context yet. We had talked about supporting Intel GPU's as well, but have done very little testing in that regard. I believe the plan for intel is to try to match the driver of the host and the container.

[rhaschke]

I've got xvfb running in docker. See #33.