Contents
Turning off hardware acceleration
If your system uses the Mesa graphics drivers (e.g. for Intel GPUs, inside a VM), hardware acceleration can cause problems. To get around this, disable this before running RViz:
export LIBGL_ALWAYS_SOFTWARE=1 rosrun rviz rviz
Problems you may encounter
Help! My data is not showing up!
RViz uses tf to transform data based on the frame_id and stamp members in the message header (roslib/Header). tf issues are the most common reason for data to fail to be displayed.
There are generally three reasons for failure along these lines:
You don't have a tf transform tree set up. Possibel solution in this case:
Set both the Fixed and Target Frames to the same value as what is specified in the frame_id for the topic that is not receiving data.
- Find a node that is supposed to be running but actually not, by following steps.
Run the following. Usually robot_state_publisher is supposed to publish tf.
rostopic echo /tf rostopic info /tf
Run this, then you see it subscribes to /joint_states.
rosnode info robot_state_publisher
Find the node that's supposed to publish the topic:rostopic echo /joint_states rostopic info joint_states
Check if rosparam use_siim_time returns true, but there's no /clock topic being published. This means you're expecting to run the robot on simulation but `Gazebo` that publishes the topic might not been running. In this case run rosparam set use_sim_time false.
You have a transform tree. Make sure the Fixed Frame is set to a frame that exists in your system. You can use the TF Display to help see if you have your frames set right.
You have a transform tree, and the Fixed Frame exists in it. This is often a timing or frame problem. See the tf troubleshooting page for more information.
Another common reason for nothing showing up is if the data being displayed is not visible from your current view. Try moving around, zooming in/out, or possibly switching to the top-down orthographic view to find out where things are.
OpenGL-related crashes
"Cannot create GL vertex buffer"
[ERROR] [1315474799.086848538]: Caught exception while loading: OGRE EXCEPTION(7:InternalErrorException): Cannot create GL vertex buffer in GLHardwareVertexBuffer::GLHardwareVertexBuffer at /tmp/buildd/ros-electric-visualization-common-1.6.0/debian/ros-electric-visualization-common/opt/ros/electric/stacks/visualization_common/ogre/build/ogre_src_v1-7-1/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp (line 46)
This is caused by a lack of the GL_ARB_vertex_buffer_object OpenGL extension. I have seen two causes for this apparent lack:
- Running rviz remotely (which is not supported)
- Version mismatch between libGL.so and the OpenGL driver.
More details and a fix for the mismatch are at ROS Answers - rviz-in-ros-electric.
No OpenGL Support
OgreGLSupport.cpp:57: virtual void Ogre::GLSupport::initialiseExtensions(): Assertion `pcVer && "Problems getting GL version string using glGetString"' failed.
This means you don't have OpenGL support available. Running through a virtualization environment that does not support hardware accelerated 3D is a common cause of this, as is not having the correct drivers installed under Linux.
In general, if there are proprietary graphics drivers for your hardware in Linux, use them instead of the (non accelerated) open source ones.
"No GLX FBConfig support" under VirtualBox
OGRE EXCEPTION(3:RenderingAPIException): No GLX FBConfig support on your display in GLXGLSupport::GLXGLSupport at OgreGLXGLSupport.cpp
Unfortunately, hardware accelerated 3D in VirtualBox is still experimental, and this is a known issue with Ogre + VirtualBox.
Segfault during startup
Various OpenGL or Ogre things can go wrong during startup. One of them seems to relate to the render-to-texture system. Ogre supports 3 different modes, and rviz uses the "PBuffer" mode by default. Some users have reported some modes cause a segfault during startup, but it is not clear which should be used when.
If you have a problem and want to try another "RTT mode", run rviz with the environment variable OGRE_RTT_MODE set to either "Copy", "PBuffer", or "FBO". For example:
export OGRE_RTT_MODE=Copy
For the discussion and to give feedback about what works and what doesn't, please see this bug report.
Other crashes
"Zero sized texture surface"
terminate called after throwing an instance of 'Ogre::RenderingAPIException' what(): OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface on texture NavViewMapTexture0 face 0 mipmap 0. Probably, the GL driver refused to create the texture. in GLTexture::_createSurfaceList at OgreGLTexture.cpp (line 394)
This is caused by using a Map Display on a graphics card that does not support textures larger than 2048 pixels on a side. Fixed in version 0.3
Segfault in i915_dri.so
This is a bug in the intel graphics driver on certain Linux systems -- Ubuntu Intrepid and Jaunty are known to have this issue. There is currently no known fix/workaround except upgrading to Ubuntu Karmic or downgrading to Ubuntu Hardy.
The callstack for this crash looks similar to:
#0 0x00007febd7378a8b in ?? () from /usr/lib/dri/i915_dri.so
#1 0x00007febd7390d8a in ?? () from /usr/lib/dri/i915_dri.so
#2 0x00007febd73868ef in _tnl_run_pipeline () from /usr/lib/dri/i915_dri.so
#3 0x00007febd72df7c4 in ?? () from /usr/lib/dri/i915_dri.so
#4 0x00007febd7386eb0 in _tnl_draw_prims () from /usr/lib/dri/i915_dri.so
#5 0x00007febd737f88e in ?? () from /usr/lib/dri/i915_dri.so
#6 0x00007febd72ac5d1 in intel_clear_tris () from /usr/lib/dri/i915_dri.so
#7 0x00007febd72aca67 in ?? () from /usr/lib/dri/i915_dri.so
#8 0x00007febd773394d in Ogre::GLRenderSystem::clearFrameBuffer (
this=0x7febd7a24d28, buffers=<value optimized out>,
colour=<value optimized out>, depth=1, stencil=0)
at OgreGLRenderSystem.cpp:3119
#9 0x00007febebcee5f7 in Ogre::SceneManager::_renderScene (
this=0x7febd7a629c8, camera=0x7febd7a29638, vp=0x7febd7a28cc8,
includeOverlays=<value optimized out>) at OgreSceneManager.cpp:1345
#10 0x00007febebcc274c in Ogre::RenderTarget::updateImpl (this=0x7febd7a268a8)
at OgreRenderTarget.cpp:113
#11 0x00007febebcc22dc in Ogre::RenderTarget::update (this=0x1f24288, swap=160)
at OgreRenderTarget.cpp:501
#12 0x00007febebcae42f in Ogre::RenderSystem::_updateAllRenderTargets (
this=<value optimized out>, swapBuffers=false) at OgreRenderSystem.cpp:112
#13 0x00007febebce0e55 in Ogre::Root::_updateAllRenderTargets (
this=0x7febd7a21908) at OgreRoot.cpp:1136
...and the output on the command line may include:
get fences failed: -1 param: 6, val: 0
Bad Drawable
(From http://www.cse.sc.edu/~jokane/teaching/574/notes-turtlebot-sim.pdf
Depending on the specific hardware on which you run RViz, you may sometimes see errors when you attempt to start RViz. This could be either a dreaded “Segmentation Fault”, or an error about something called a “Bad Drawable”. In both cases, the error is fatal but intermittent. This is a symptom of a known bug when RViz is used with certain video cards. (See Section 2). There are two workarounds you can try.
- First, you can try setting the environment variable OGRE_RTT_MODE to one of these three strings: Copy, PBuffer, or FBO. This setting changes some of the internal details of how the window is rendered. Depending on your configuration, you may have better success with one of these options than others.
- Second, since the problem is intermittent, you can simply try starting RViz again and again until it succeeds. The best way to do this is to use a launch file, and include respawn="true" in the node tag for RViz.
For more detail, see this ticket
Multiple Monitors
Some graphics drivers don't like when a 3D accelerated application spans multiple monitors. Some drivers even only accelerate the primary display. In either of these cases rviz may become slow or unresponsive.
In the first case, simply prevent the 3D window from spanning multiple monitors. In the second, open rviz on your primary display.
How to make a usable bug report
If you haven't found a solution on this page, on ROS Answers, or a Google search (the Ogre3D package has a great discussion forum for instance), please follow these instructions when reporting a bug.
We need a lot of data about a crash or other failure in order to understand the cause. Please include as much of this data as you can.
rosrun rviz system_info.sh This command prints basic information about your OS and graphics card. Include the output of this.
Ogre.log Run rviz with the "-l" option rosrun rviz rviz -l to produce an "Ogre.log" file in the current directory. Include the Ogre.log file.
- rviz output. rviz prints a bunch of useful info at the start, like the Ogre version number, the RTT mode, etc. Plus lots of potentially-relevant warning and error messages. Include the rviz console output. If you have to leave some out to make it a reasonable size, leave in the start and end portions at least.
- Stack trace. Run rviz in gdb, wait for your crash to happen, then type "backtrace". Include the full results.
- Core file. A core file is a dump of all the memory in use by a program when it crashed, so gives even more info than a stack trace. To get a core file (in linux, specifically in the "bash" shell) do:
ulimit -c unlimited to remove the core file size limit (default is size 0).
- run rviz and cause the crash.
- a file named "core" or similar (sometimes with a process ID number in the name) should appear in the current directory. Include the core file.
Include as much of this info as you can and report the bug on Rviz Github Issues
Or ask a question about it on ROS Answers
Please search the existing tickets and questions before posting to make sure yours is not a duplicate.
Thanks!
