![]() This is a bug in the intel graphics driver on certain Linux systems - Ubuntu Intrepid and Jaunty are known to have this issue. This is caused by using a Map Display on a graphics card that does not support textures larger than 2048 pixels on a side. in GLTexture::_createSurfaceList at OgreGLTexture.cpp (line 394) ![]() Probably, the GL driver refused to create the texture. What(): OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface on texture NavViewMapTexture0 face 0 mipmap 0. Terminate called after throwing an instance of 'Ogre::RenderingAPIException' For example: export OGRE_RTT_MODE=Copyįor the discussion and to give feedback about what works and what doesn't, please see this bug report. 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". Some users have reported some modes cause a segfault during startup, but it is not clear which should be used when. Ogre supports 3 different modes, and rviz uses the "PBuffer" mode by default. One of them seems to relate to the render-to-texture system. Various OpenGL or Ogre things can go wrong during startup. Unfortunately, hardware accelerated 3D in VirtualBox is still experimental, and this is a known issue with Ogre + VirtualBox. Your display in GLXGLSupport::GLXGLSupport at OgreGLXGLSupport.cpp OGRE EXCEPTION(3:RenderingAPIException): No GLX FBConfig support on "No GLX FBConfig support" under VirtualBox In general, if there are proprietary graphics drivers for your hardware in Linux, use them instead of the (non accelerated) open source ones. 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. This means you don't have OpenGL support available. OgreGLSupport.cpp:57: virtual void Ogre::GLSupport::initialiseExtensions(): Assertion `pcVer & "Problems getting GL version string using glGetString"' failed. More details and a fix for the mismatch are at ROS Answers - rviz-in-ros-electric. Version mismatch between libGL.so and the OpenGL driver.Running rviz remotely (which is not supported).I have seen two causes for this apparent lack: This is caused by a lack of the GL_ARB_vertex_buffer_object OpenGL extension. ![]() : 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) Try moving around, zooming in/out, or possibly switching to the top-down orthographic view to find out where things are. See the tf troubleshooting page for more information.Īnother common reason for nothing showing up is if the data being displayed is not visible from your current view. You have a transform tree, and the Fixed Frame exists in it. You can use the TF Display to help see if you have your frames set right. Make sure the Fixed Frame is set to a frame that exists in your system. In this case run rosparam set use_sim_time false. This means you're expecting to run the robot on simulation but `Gazebo` that publishes the topic might not been running. ![]() rosnode info robot_state_publisher Find the node that's supposed to publish the topic: rostopic echo /joint_statesĬheck if rosparam use_siim_time returns true, but there's no /clock topic being published. Run this, then you see it subscribes to /joint_states. Usually robot_state_publisher is supposed to publish tf. Find a node that is supposed to be running but actually not, by following steps.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. You don't have a tf transform tree set up. There are generally three reasons for failure along these lines: tf issues are the most common reason for data to fail to be displayed. RViz uses tf to transform data based on the frame_id and stamp members in the message header ( roslib/Header). To get around this, disable this before running RViz: for Intel GPUs, inside a VM), hardware acceleration can cause problems. If your system uses the Mesa graphics drivers (e.g. "No GLX FBConfig support" under VirtualBox.
0 Comments
Leave a Reply. |