0
$\begingroup$

Gazebo Answers logo

Last week, my plugins were working. Without having changed anything, this week the visual plugin crashes. Does anyone have any insights into what's going on or how to fix this? Does anyone else get the same error on compiling the plugin and using it with the world file below?


[Edit Sept. 19 '16: I did change something, which I had forgotten about. As alluded to in the edited title of the question, I attempted to add a directory to the GAZEBO_RESOURCE_PATH in .bashrc -- see the issue URL in the comment below. This problem had nothing whatsoever to do with my visual plugin.]


Here's the error:

gzclient: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::rendering::Camera; typename boost::detail::sp_member_access<T>::type = gazebo::rendering::Camera*]: Assertion `px != 0' failed.
Aborted (core dumped)

Here are the only files necessary to reproduce the crash:

Visual plugin:

#include <gazebo/gazebo.hh>
#include <gazebo/common/common.hh>
#include <gazebo/rendering/rendering.hh>
#include <stdio.h>

namespace gazebo
{ class SpacenavVisualPlugin : public VisualPlugin
  { public: 

      // Constructor
      SpacenavVisualPlugin() : VisualPlugin()
      { printf( "SpacenavVisualPlugin started\n" ); // DEBUG
      }

      // Destructor
      ~SpacenavVisualPlugin() // : ~VisualPlugin()
      { printf( "SpacenavVisualPlugin stopped\n" ); // DEBUG
      }

      void Load( rendering::VisualPtr _visual, sdf::ElementPtr /*_sdf*/)
      { // === Turn off the SpaceNavigator's default camera control
        rendering::ScenePtr scene = _visual->GetScene();
        rendering::UserCameraPtr cam = scene->GetUserCamera( 0 );
        cam->SetJoyPoseControl( false );
        cam->SetJoyTwistControl( false );
      }
  };

  // Register this plugin with the simulator
  GZ_REGISTER_VISUAL_PLUGIN( SpacenavVisualPlugin )
};

World file:

<?xml version="1.0" ?>
<sdf version="1.5">
  <world name="default">

    <include>
      <uri>model://ground_plane</uri>
    </include>

    <include>
      <uri>model://sun</uri>
    </include>

    <!-- model just to hold plugin that turns off spacenav camera control  -->
    <model name="dummy_model">
      <link name="dummy">
        <collision name="collision">
          <geometry>
            <box>
              <size>1 1 1</size>
            </box>
          </geometry>
        </collision>
        <visual name="visual">
          <geometry>
            <box>
              <size>1 1 1</size>
            </box>
          </geometry>
          <plugin name="spacenavVisualPlugin" filename="/home/jason/libspacenavVisualPlugin.so"/>
        </visual>
      </link>
    </model>

  </world>
</sdf>

The commands I run are gzserver test.world and, in a separate terminal window, gzclient. The abort back to the prompt happens almost immediately after the second command, just a split second after the gazebo splash screen and the main window are drawn. Then I can quit the first command in its terminal window with CTRL-c.

Here is the question where I describe the need for the visual plugin. The problem seems to be related to this question; i.e., the plugin is somehow running before the rendering engine is initialized, but I don't know of any other way to turn off the Space Navigator other than the visual plugin.


Originally posted by JasonMel on Gazebo Answers with karma: 35 on 2016-08-29

Post score: 0


Original comments

Comment by chapulina on 2016-08-31:
I am not able to reproduce your problem, what Gazebo version are you using? The world loads fine and I see the "SpacenavVisualPlugin started" and "SpacenavVisualPlugin stopped" messages. You could try running it through gdb.

Comment by JasonMel on 2016-08-31:
Thank you! It'll probably be next week before I can follow up, but I'll get back to you.

Comment by JasonMel on 2016-09-06:
@chapulina Actually, I've realized that Gazebo doesn't even work when running gzserver empty.world with the presupplied empty.world and running gzclient in another terminal. The gzserver seems to work, but the gzclient loads the spash screen and the main window border, outputs the error I quoted in the question, and quits. Then I CTRL-c out of the gzserver. Gazebo works fine if launched via the launcher, however. The major version is 7, but I'm not sure what the minor and patch versions are.

Comment by chapulina on 2016-09-06:
That sounds like a bug... You could ticket an issue at Bitbucket detailing your computer specs and how you installed Gazebo. https://bitbucket.org/osrf/gazebo/issues/new

Comment by nkoenig on 2016-09-07:
This is an odd error. The gazebo command just runs gzserver and gzclient in separate processes. If gazebo works, then separate invocations of gzserver and gzclient should as well. You might see this type of error if you have multiple (and different) versions of Gazebo installed.

Comment by Omer on 2016-09-10:
Did anyone manage to solve this problem? I'm still seeing it.

Comment by JasonMel on 2016-09-12:
@Omer Yeah, there's a fix at https://bitbucket.org/osrf/gazebo/issues/2044/gazebo-731-gzserver-gzclient-results-in that worked for me. I haven't typed up an answer here because I'd like to see how the issue discussion plays out.

$\endgroup$

1 Answer 1

0
$\begingroup$

Gazebo Answers logo

As I indicated in my edit, this problem has nothing to do with any plugins. It was caused by attempting, in .bashrc, to modify environment variables, GAZEBO_MODEL_PATH and GAZEBO_RESOURCE_PATH, that had never been set. As Steven Peters pointed out in the bug tracker issue, this entire problem can be fixed by putting the line

source /usr/share/gazebo/setup.sh

above any lines that customize the Gazebo paths, such as

export GAZEBO_MODEL_PATH=${GAZEBO_MODEL_PATH}:<new_path>
export GAZEBO_RESOURCE_PATH=${GAZEBO_RESOURCE_PATH}:<new_path>

in .bashrc. The Getting Started tutorial mentions the need to do this.


Originally posted by JasonMel with karma: 35 on 2016-09-20

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by Kapil on 2019-10-07:
Thanks!, this helped.

Comment by arthur118 on 2023-01-26:
Thanks! This answer solved my problem.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.