Ask Your Question

gazebo crashes on start, shared_ptr error.

asked 2012-04-04 15:50:53 -0600

Capelare gravatar image

Hi! I was writing a plugin for a NXT robot I made and after studying erratic's diffdrive_plugin and turtlebot's gazebo_ros_create I think it's ready for a first test ride. But when I try to launch my robot (with a launch file of my own), and a .urdf.xacro of my own(inspired by erratic's and turtlebot's too) I get this error:

started core service [/rosout]
process[gazebo-2]: started with pid [11942]
process[spawn_robot-3]: started with pid [11943]
process[robot_state_publisher-4]: started with pid [11944]
Gazebo multi-robot simulator, version 0.10.0

Part of the Player/Stage Project [].
Copyright (C) 2003 Nate Koenig, Andrew Howard, and contributors.
Released under the GNU General Public License.

Param [quickStepPreconIters] is deprecated: [replace quickStepPreconIters with stepPreconIters]
Param [quickStep] is deprecated: [replace quickStep with stepType]
Param [quickStepIters] is deprecated: [replace quickStepIters with stepIters]
Param [quickStepW] is deprecated: [replace quickStepW with stepW]
Gazebo successfully initialized
[ INFO] [1333588639.189278494]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[INFO] [WallTime: 1333588639.485998] [0.001000] waiting for service spawn_urdf_model
gazebo: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr<T>::operator->() const [with T = urdf::Inertial]: Assertion `px != 0' failed.
[ERROR] [WallTime: 1333588639.555503] [0.001000] Service call failed: transport error completing service call: unable to receive data from sender, check sender's logs for details
[gazebo-2] process has died [pid 11942, exit code -6].
log files: /home/capelare/.ros/log/15a68e96-7ebd-11e1-9ab0-e0cb4e93305d/gazebo-2*.log
[spawn_robot-3] process has finished cleanly.
log file: /home/capelare/.ros/log/15a68e96-7ebd-11e1-9ab0-e0cb4e93305d/spawn_robot-3*.log

I understand that I'm using a shared pointer without having initialized it first... maybe it's something about the subscriber to the cmd_vel node? :-\

This is the content of the spawn_robot-3.log file, BTW, there's no gazebo-2*.log file:

[rospy.client][INFO] 2012-04-05 03:17:18,230: init_node, name[/spawn_robot], pid[11943]
[xmlrpc][INFO] 2012-04-05 03:17:18,230: XML-RPC server binding to
[xmlrpc][INFO] 2012-04-05 03:17:18,231: Started XML-RPC server [http://Ubunti7:46395/]
[rospy.init][INFO] 2012-04-05 03:17:18,231: ROS Slave URI: [http://Ubunti7:46395/]
[rospy.impl.masterslave][INFO] 2012-04-05 03:17:18,231: _ready: http://Ubunti7:46395/
[rospy.registration][INFO] 2012-04-05 03:17:18,232: Registering with master node http://localhost:11311
[xmlrpc][INFO] 2012-04-05 03:17:18,232: xml rpc node: starting XML-RPC server
[rospy.init][INFO] 2012-04-05 03:17:18,331: registered with master
[rospy.rosout][INFO] 2012-04-05 03:17:18,367: initializing /rosout core topic
[rospy.rosout][INFO] 2012-04-05 03:17:18,369: connected to core topic /rosout
[rospy.simtime][INFO] 2012-04-05 03:17:18,370: initializing /clock core topic
[rospy.simtime][INFO] 2012-04-05 03:17:18,371: connected to core topic /clock
[rosout][INFO] 2012-04-05 03:17:19,485: waiting for service spawn_urdf_model
[rosout][ERROR] 2012-04-05 03:17:19,555: Service call failed: transport error completing service call: unable to receive data from sender, check sender's logs for details
[rospy.core ...
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2012-04-04 16:59:35 -0600

The shared_ptr assertion mentions the type urdf::Inertial. Assuming your plugin does not mess around with this, maybe you forgot a required <inertial> node in your URDF file, and Gazebo crashes when it tries to access that?

edit flag offensive delete link more


Well, you made me feel a little bit stupid for not thinking about that myself... In my defense I'll say that I didn't even know that the <inertial> tag was mandatory for every link :P

Capelare gravatar image Capelare  ( 2012-04-04 18:40:27 -0600 )edit

Now seriously, that seems to get rid of the problem, although new errors come to the surface! I hope to be able of solving them by myself... ;-) Thanks a lot!! :D

Capelare gravatar image Capelare  ( 2012-04-04 18:45:33 -0600 )edit

Don't feel too bad about this. Asserting on a NULL pointer is not exactly a user-friendly error message when it comes to invalid configurations. Unfortunately for Gazebo, this was even one of the more useful ones.

roehling gravatar image roehling  ( 2012-04-05 01:20:08 -0600 )edit

hey, I'm facing the same issue trying to spawn an heightmap in gazebo. However, the shared pointer mentioned with T = gazebo::msgs::Response; typename boost::detail::sp_member_access<t>::type = gazebo::msgs::Response*

I don't want to have any gazebo message in my heightmap, though. Any idea?

GuillaumeHauss gravatar image GuillaumeHauss  ( 2017-10-13 04:29:01 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2012-04-04 15:50:53 -0600

Seen: 1,962 times

Last updated: Apr 04 '12