ros-simulation / gazebo_ros_pkgs Goto Github PK

The State and Property setters in this tutorial: http://gazebosim.org/wiki/Tutorials/1.9/ROS_Communication_with_GazeboAlmost all say "This service allows the user to set properties of a link in simulation." They need to be changed to what they actually do.

Using a JointVelocityController with an apparently small derivative gain, such as 0.01, results in large effort values being sent to Gazebo. If Gazebo 1.9.1 receives such a large effort value, it moves many of the model's links to the world origin, making the model unusable. Ultimately, this appears to be a Gazebo bug. In any case, though, controllers should obey the position, velocity, and effort limits specified in the URDF file. I have found that if the effort is clamped to the limit specified in the URDF, the "links moved to the origin" problem is avoided.

I made changes to the effort-based joint position and velocity controllers in ros_controllers, enforcing the velocity and effort limits specified in the URDF. However, Adolfo Rodriguez Tsouroukdissian pointed out that a better solution is to add a joint limits interface to default_robot_hw_sim.cpp. My questions are:

1. Is anyone already implementing this feature?
2. If not, does anyone have any objections to me adding it?

The GUI gets loaded by default when you run the gazebo script. This behavior is different from simulator-gazebo. Is this intended?

When compiling hydro-devel:

In file included from /home/dave/ros/ws_baxter/src/gazebo_ros_pkgs/gazebo_plugins/src/gazebo_ros_projector.cpp:29:0:
/usr/include/gazebo-1.9/gazebo/rendering/Rendering.hh:21:2: warning: #warning The gazebo/rendering/Rendering.hh header file is deprecated as of gazebo 1.9 and will be removed in the next release. Please include gazebo/rendering/Rendering\
Iface.hh instead. [-Wcpp]

Downstream bug report: utexas-bwi/segbot_simulator#11

This is a low priority bug for me. If one of you guys can spot any obvious problems, then let me know. Otherwise I will follow up on this once the new version of gazebo/sdformat/gazebo-ros-pkgs and segbot-simulator have been released (making it easier to reproduce the error).

Both robots Initialize at Screenshot 1.

• Both robots are running a very simple collision model and have 1 collision element each.
• They use gazebo_ros_openni_kinect as a simulated kinect sensor
• They move inside gazebo using gazebo_ros_planar_move.

Note the bubble in the depth image for robot 1 in the bottom left hand corner. As robot 2 moves away, the depth image changes and eventually the bubble goes away.
Screenshot 2
Screenshot 3
Screenshot 4

This problem does not exist with a single robot. It seems like multiple depth cameras are somehow interfering with one another.

Thanks!
Piyush

Mud world is seg faulting (the other three example worlds are working fine). I get this error:
Segmentation fault (core dumped)
[gazebo-1] process has died [pid 29545, exit code 139, cmd /home/heather/catkin_ws/src/gazebo_ros_pkgs/gazebo_ros/scripts/gzserver worlds/mud.world __name:=gazebo __log:=/home/heather/.ros/log/dd880d2e-d856-11e2-8621-902b34d2e9d3/gazebo-1.log].
log file: /home/heather/.ros/log/dd880d2e-d856-11e2-8621-902b34d2e9d3/gazebo-1*.log

That log file does not exist as far as I can tell.

RMF = Robot Modeling Format, Gazebo's rename of SDF

the include/gazebo directory in gazebo_ros package should have been renamed to include/gazebo_ros to differentiate these two different code bases:

#include <gazebo/common/Events.hh>
#include <gazebo/gazebo_ros_api_plugin.h>

Gazebo 2.0.0 is going to be released today, probably during the following hours. Due to the changes in the API/ABI it would be nice to have a new release of gazebo_ros_pkgs 2.3.3 for both devel branches: hydro-devel and groovy--devel.

After that, gazebo_ros_pkgs-release (using bloom) and ros repository should take care of hydro release and OSRF jenkins and repository will host groovy versions. If there are any changes to API/ABI in gazebo_ros_pkgs for hydro, all the packages depending on it should be rebuilt.

I will comment when all gazebo 2.0.0 versions are in place.

I'm building ROS Hydro on Debian Wheezy,and am getting build errors. I have built gazebo from source and installed it with my package manager. In this issue make is unable to find Rendering.hh because it was named differently in gazebo's include library.

$ cd /home/peter/Documents/ros_workspace/build_isolated/gazebo_plugins && /home/peter/Documents/ros_workspace/hydro/env.sh make -j4 -l4 --debug=v
...
/home/peter/Documents/ros_workspace/src/gazebo_plugins/src/gazebo_ros_projector.cpp:29:41: fatal error: gazebo/rendering/Rendering.hh: No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/gazebo_ros_projector.dir/src/gazebo_ros_projector.cpp.o] Error 1
make[1]: *** [CMakeFiles/gazebo_ros_projector.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2

$sudo find / -name "*endering.hh" -type f
/usr/local/include/gazebo-1.9/gazebo/rendering/rendering.hh
/home/peter/Documents/ros_workspace/external_src/gazebo/gazebo/rendering/rendering.hh

$ find /home/peter/Documents/ros_workspace/build_isolated/gazebo_plugins -type f -exec grep Rendering.hh {} +
/home/peter/Documents/ros_workspace/build_isolated/gazebo_plugins/CMakeFiles/gazebo_ros_projector.dir/CXX.includecache:gazebo/rendering/Rendering.hh

$ find / -type f -exec grep Rendering.hh {} +
/home/peter/Documents/ros_workspace/build_error:/home/peter/Documents/ros_workspace/build_isolated/gazebo_plugins/CMakeFiles/gazebo_ros_projector.dir/CXX.includecache:gazebo/rendering/Rendering.hh
/home/peter/Documents/ros_workspace/build_error:/home/peter/Documents/ros_workspace/src/gazebo_plugins/src/gazebo_ros_projector.cpp:29:41: fatal error: gazebo/rendering/Rendering.hh: No such file or directory
/home/peter/Documents/ros_workspace/src/gazebo_plugins/src/gazebo_ros_projector.cpp:#include <gazebo/rendering/Rendering.hh>

The fix is:
cp /usr/local/include/gazebo-1.9/gazebo/rendering/rendering.hh /usr/local/include/gazebo-1.9/gazebo/rendering/Rendering.hh

This is how I installed gazebo (9/28/2013):
hg clone https://bitbucket.org/osrf/gazebo gazebo
cd gazebo
cmake .
sudo checkinstall make install

Either gazebo needs to install that file as Rendering.hh or gazebo_ros_projector.cpp needs to include rendering.hh instead. I'm new to this process so I'm not sure how implement the fix myself.

Calling

rosservice call /gazebo/get_link_state "link_name: 'rrbot'
reference_frame: 'world'" 

On the default RRBot launch file with a coke can added causes:

gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr<T>::operator->() const [with T = gazebo::physics::Link]: Assertion `px != 0' failed.
Aborted (core dumped)
[gazebo-2] process has died [pid 23334, exit code 134, cmd /home/dave/ros/misc/src/gazebo_ros_pkgs/gazebo_ros/scripts/gzserver /home/dave/ros/misc/src/gazebo_ros_demos/rrbot_gazebo/world/rrbot.world __name:=gazebo __log:=/home/dave/.ros/log/a0f68a94-d260-11e2-8b8b-10bf4885b91f/gazebo-2.log].
log file: /home/dave/.ros/log/a0f68a94-d260-11e2-8b8b-10bf4885b91f/gazebo-2*.log

Baxter spawns in the world, but is not visible because he is falling off the map (the z value in pose just gets more and more negative).

Hi

It looks like that the gazebo_ros_diff_drive plug-in cases the gzserver to crash when a robot is removed (deleted) from the world

Ubuntu 12.04 (32bit)
ROS Hydro

Greetings

To fix error

/usr/include/gazebo-1.9/gazebo/transport/Connection.hh:20:22: fatal error: tbb/task.h: No such file or directory

Use this code snippet?

 #################################################                                                                                                     
  # Find TBB                                                                                                                                            
  pkg_check_modules(TBB tbb)
  if (NOT TBB_FOUND)
    message(STATUS "TBB not found, attempting to detect manually")

    find_library(tbb_library tbb ENV LD_LIBRARY_PATH)
    if (tbb_library)
      set(TBB_FOUND true)
      set(TBB_LIBRARIES ${tbb_library})
    else (tbb_library)
      BUILD_ERROR ("Missing: TBB - Threading Building Blocks")
    endif(tbb_library)
  endif (NOT TBB_FOUND)

Why is there a gazebo_media_path, plugin_path, and gazebo_model_path in gazebo_ros_paths_plugin.cpp? What are those used for, where, and do we need all three?

@hsu

Currently only supports stereo cameras. Update documentation here when fixed:
http://gazebosim.org/wiki/Tutorials/1.9/ROS_Motor_and_Sensor_Plugins#Multicamera

Should the namespace tag in the gazebo_ros_control plugin XML be clearer than "robotNamespace" since it only affects the ros_control plugin? Maybe "rosNamespace" or "controllerNamespace" or something like that?

Inline TODO: https://github.com/osrf/gazebo_ros_pkgs/blob/hydro-devel/gazebo_ros_control/src/ros_control_plugin.cpp#L112

I have a simple differential drive plugin here based on the original differential drive plugin from the erratic_robot package: https://github.com/utexas-bwi/segbot_simulator/blob/master/segbot_gazebo_plugins/src/diff_drive_plugin.cc

This works as expected with simulator_gazebo-1.7.12 (Gazebo 1.5), but getWorldPose() seems to be returning ~0 for position with Gazebo 1.8.6. The position does not change even slightly over time, and the orientation changes somewhat arbitrarily.:

pose: 
  pose: 
    position: 
      x: 6.91499350184e-310
      y: 6.91499350199e-310
      z: 0.0

On the other hand /gazebo/get_model/state seems to be returning the correct value. Since it uses the getWorldPose under the hood, I am not sure what the difference is. I am also unsure whether this is an upstream issue or not, but it is something that might be nice to document in gazebo_ros_pkgs migration.

https://github.com/ros-simulation/gazebo_ros_pkgs/blob/hydro-devel/gazebo_ros_control/README.md

Should read:

  <transmission name="tran1">
    <type>transmission_interface/SimpleTransmission</type>
    <joint name="joint1"/>
    <actuator name="motor1">
      <hardwareInterface>EffortJointInterface</hardwareInterface>
      <mechanicalReduction>1</mechanicalReduction>
    </actuator>
  </transmission>

As of the recent merge of PR #46, the ros_control plugin is informed of the joints it should control by <actuator> tags in the XDF and then the API constructs JointData structures for each joint. I feel like some of the information is muddled here between joint-specific information, actuator-specific information, and transmission-specific information.

One thing that I find a bit confusing is whether or not we're assuming joint-level control or actuator control. From my perspective, it looks like if you're using tags then you're assuming you have actuator-level control, and you need to convert from joint-space to actuator-space.

But now, even if you have joint-level control (gazebo API and many common C++ hardware APIs) you still need to have <transmission> and you classify each of them as a SimpleTransmission even though there might be a non-trivial transmission which is accounted for by a lower-level system.

@adolfo-rt @davetcoleman

Within gazebo_ros_paths_plugin.cpp we should switch the functions rosPackageCommandDebug and rosPackageGetPluginsDebug to use the native ros::package::command() and getPlugins() functions now that the 3 yr old ticket is fixed.
https://code.ros.org/trac/ros/ticket/2977

CMake Error at CMakeLists.txt:35 (find_package):
  Could not find module Findgazebo.cmake or a configuration file for package
  gazebo.

  Adjust CMAKE_MODULE_PATH to find Findgazebo.cmake or set gazebo_DIR to the
  directory containing a CMake configuration file for gazebo.  The file will
  have one of the following names:

    gazeboConfig.cmake
    gazebo-config.cmake



CMake Error at CMakeLists.txt:36 (find_package):
  Could not find module FindSDF.cmake or a configuration file for package
  SDF.

  Adjust CMAKE_MODULE_PATH to find FindSDF.cmake or set SDF_DIR to the
  directory containing a CMake configuration file for SDF.  The file will
  have one of the following names:

    SDFConfig.cmake
    sdf-config.cmake

@tfoote we set this up today together, what do you think went wrong?

Hi! I use ros hydro + gazebo 1.9.1, my os is Ubuntu 12.04 32bit. The gazebo_ros_planar_move plugin can not make the model in touch with the ground when moving, which means that the model just "floats" above the ground when it is put there (by spawn or manual translation in gazebo gui) with this plugin (when without this plugin, the model falls down quickly as expected). I suppose the problem comes from that the linear velocity of z direction of the model is set to zero, and it is also not suitable to set this velocity to some constant value, then the model would stick to the ground, and it is quite difficult for the model to move away. I understand that this is just a simple plugin for the model motion control in gazebo, but I still hope there could be some possible solutions for this issue. Thanks for any help!

They started as dirty duplicate code, need to consolidate and deprecate one of them.

Hi,

I could not change the position of an robot when spawning them using roslaunch/rosrun. The problem appears when the robot is defined in SDF with a element in the robots element

it seems like the position is just appended to the old position

I could fix this for me by editing the updateSDFAttributes Function in the file gazebo_ros_api_plugin.cpp...

I changing the last lines there

from:

TiXmlText* text = new TiXmlText(pose_stream.str());   
pose_element->LinkEndChild( text );

to:

TiXmlText* text = new TiXmlText(pose_stream.str());   
pose_element->Clear();
pose_element->LinkEndChild( text );

This is probably not the best solution because the pose will be overwritten with 0 values if no position is specified...

I'm currently not sure if position of robots are overwritten in general even if there is no position specified when running the spawn_model script...

A recent pull request is causing the following warnings at Gazebo's startup

[rospack] Warning: no such package gazebo
[rospack] Warning: no such package gazebo
[rospack] Warning: no such package gazebo
[rospack] Warning: no such package gazebo
[rospack] Warning: no such package gazebo
[rospack] Warning: no such package gazebo

Because there is no longer a package called "gazebo". I think we need to undo the previous fix even though it will break backwards compatibility with plugins. It's not gazebo_ros_pkg's fault that Gazebo is now a standalone dependency.

When I include empty_world.launch in my launch file, I get the following errors/warnings

[rospack] Warning: no such package gazebo_ros                                                                                                                                                                                                                                                                                
[rospack] Warning: no such package gazebo_ros                                                                                                                                                                                                                                                                                
[rospack] Warning: no such package gazebo_ros                                                                                                                                                                                                                                                                                
[rospack] Warning: no such package gazebo_ros                                                                                                                                                                                                                                                                                
[rospack] Warning: no such package gazebo_ros                                                                                                                                                                                                                                                                                
[rospack] Warning: no such package gazebo_ros                                                                                                                                                                                                                                                                                
[rospack] Error: stack/package gazebo_ros not found                                                                                                                                                                                                                                                                          
[librospack]: error while executing command                                                                                                                                                                                                                                                                                  
[rospack] Error: stack/package gazebo_ros not found                                                                                                                                                                                                                                                                          
[librospack]: error while executing command                

whereas roscd and rospack find both can find that package.

When I try to spawn a model using an urdf, it often gives me a similar error saying it cannot find the package where the URDF is located.

Does anybody know what's going on? Is there any changing of environment variables inside gazebo_ros?

@davetcoleman

This breaks the buildfarm: http://jenkins.willowgarage.com:8080/job/_hydro-reconfigure-release-jobs/136/console

Traceback (most recent call last):
  File "./scripts/create_release_jobs.py", line 211, in <module>
    release_jobs.check_for_circular_dependencies(dependencies)
  File "/var/lib/jenkins/jobs/_hydro-reconfigure-release-jobs/workspace/buildfarm/release_jobs.py", line 125, in check_for_circular_dependencies
    _remove_leafs_recursively(rev_deps)
  File "/var/lib/jenkins/jobs/_hydro-reconfigure-release-jobs/workspace/buildfarm/release_jobs.py", line 140, in _remove_leafs_recursively
    raise RuntimeError('The following packages contain a dependency cycle: %s' % ', '.join(sorted(deps.keys())))
RuntimeError: The following packages contain a dependency cycle: ros-hydro-gazebo-plugins, ros-hydro-gazebo-ros

PCL has been updated to 1.7 on shadow-fixed, breaking all plugins that used pointclouds. Is a patch required?

After following the instructions here: http://gazebosim.org/wiki/Tutorials/1.9/Using_A_URDF_In_Gazebo, RRBot does not launch correctly in RViz as shown below. It does launch correctly in Gazebo.

The "Documentation on ros_control's transmission_interface" link on this tutorial: http://gazebosim.org/wiki/Tutorials/1.9/ROS_Control_with_Gazebo is broken.

"rosrun gazebo_ros spawn_model -file rospack find baxter_description/urdf/baxter.urdf -urdf -z 1 -model baxter"
is not working for me. It's hanging after this:
rosrun gazebo_ros spawn_model -file rospack find baxter_description/urdf/baxter.urdf -urdf -z 1 -model baxter
[INFO] [WallTime: 1371588399.946251] [0.000000] Loading model xml from file
[INFO] [WallTime: 1371588399.946837] [0.000000] waiting for service /gazebo/spawn_urdf_model

In this tutorial: http://gazebosim.org/wiki/Tutorials/1.9/ROS_Communication_with_Gazebo , the coke can does not stop rotating when the negative torque is applied.

terminate called after throwing an instance of 'pluginlib::LibraryLoadException'
  what():  rospack could not find the image_transport package containing image_transport::PublisherPlugin
/opt/ros/hydro/lib/gazebo_ros/gzserver: line 17:  7965 Aborted                 (core dumped) gzserver $final

You can reproduce this by launching the turtlebot simulator:

roslaunch turtlebot_gazebo turtlebot_empty_world.launch

http://www.ros.org/wiki/turtlebot_simulator

I believe the important function to publish the camera info is

GazeboRosOpenniKinect::PublishCameraInfo()

However, I don't see anything calling it ever, which might be the cause of this issue.
For testing I have added a call of this function in OnNewDepthFrame(), but I am not sure this is the right place.

Currently when adding a gazebo sdf robot, nothing is done with the -robot_namespace argument.

Adding

this->walkChildAddRobotNamespace(&gazebo_model_xml);

at the end of the else if (IsSDF(model_xml)) (approximately line 537 of file gazebo_ros_api_plugin.cpp) adds the feature for the first level of the robot model, but the nested

<include>
  <uri>model://mymodel</uri>
</include>

are unafected as the model is not flattened. I see several solutions

1. Flatten manually every model when using spawn model.
2. Have the flattening done in the ros_api C part.
3. Have a python script doing the flattening.

This issue is mostly to know the status (as I'm sure this is known) of the feature and to inquiry any other detail I missed before trying to work on that.

#86

When starting a Gazebo simulation that includes the plugin, it says

[ INFO] Starting gazebo_ros_control plugin in namespace: /youbot0/
[ INFO]: gazebo_ros_control plugin is waiting for model URDF in parameter [/robot_description] on the ROS param server.

One would expect for it to look for /youbot0/robot_description.
Unless the /robot_description param is there, instead, it doesn't proceed.

If this is a known and required behaviour, or if the problem seems to be on my side, sorry in advance.

To allow the pose to be set. This fixes the unnecessary error:

ERROR ros.gazebo_ros: could not find <gazebo> element in sdf, so new name not applied

In gazebo_ros_pkgs/gazebo_ros/src/gazebo_ros_api_plugin.cpp function GazeboRosApiPlugin::updateSDFModelPose

After I merged ros_control_gazebo and gazebo_ros_control, there were a lot of commented-out debug and experimental blocks, could you clean these up, or move them to a branch for experimentation?

Debug: https://github.com/osrf/gazebo_ros_pkgs/blob/hydro-devel/gazebo_ros_control/src/ros_control_plugin.cpp#L103

??: https://github.com/osrf/gazebo_ros_pkgs/blob/hydro-devel/gazebo_ros_control/src/ros_control_plugin.cpp#L192

Debug: https://github.com/osrf/gazebo_ros_pkgs/blob/hydro-devel/gazebo_ros_control/src/ros_control_plugin.cpp#L302

Experimental: https://github.com/osrf/gazebo_ros_pkgs/blob/hydro-devel/gazebo_ros_control/src/ros_control_plugin.cpp#L306

Package: https://github.com/utexas-bwi/segbot_simulator/tree/stable/segbot_gazebo_plugins

Jenkins log: http://jenkins.willowgarage.com:8080/job/ros-hydro-segbot-gazebo-plugins_binarydeb_quantal_amd64/10/consoleFull

I am a bit confused by this one. The console log says that libcegui-mk2-0.7.6 was installed. Any thoughts on debugging this?

using the command line argument -J

i spent a lot of time investigating this today to no avail

@hsu

pcl_conversions was removed as a dependency for hydro-devel because it was not available for groovy-devel, but it will soon be
ros-perception/pcl_conversions#3 (comment)

This branch fixes the issue:
https://github.com/ros-simulation/gazebo_ros_pkgs/compare/hydro-pcl-conversions?expand=1

Todo:

• merge hydro-cl-conversions branch
• delete the groovy-devel branch since it will be the same as hydro-devel

I am running my Gazebo simulation at 1 kHz. This seems like overkill for my effort-based joint position and velocity controllers (servos often use a 50 Hz PID loop), so I set the gazebo_ros_control control frequency to 100 Hz, like this:

  <xacro:property name="ctrl_period" value="0.01"/>

  <gazebo>
    <plugin name="gazebo_ros_control" filename="libgazebo_ros_control.so">
      <controlPeriod>${ctrl_period}</controlPeriod>
    </plugin>
  </gazebo>

This caused my simulated vehicle's shock absorbers to stop working, and its steering to become sluggish. I mitigated (but didn't completely fix) the problem by making this modification to gazebo_ros_control_plugin.cpp:

void GazeboRosControlPlugin::Update()
{
  // Get the simulation time and period
  gazebo::common::Time gz_time_now = parent_model_->GetWorld()->GetSimTime();
  ros::Time sim_time_ros(gz_time_now.sec, gz_time_now.nsec);
  ros::Duration sim_period = sim_time_ros - last_sim_time_ros_;

#ifdef NOTDEF
  // Check if we should update the controllers
  if(sim_period >= control_period_) {
    // Store this simulation time
    last_sim_time_ros_ = sim_time_ros;

    // Update the robot simulation with the state of the gazebo model
    robot_hw_sim_->readSim(sim_time_ros, sim_period);

    // Compute the controller commands
    controller_manager_->update(sim_time_ros, sim_period);

    // Update the gazebo model with the result of the controller
    // computation
    robot_hw_sim_->writeSim(sim_time_ros, sim_period);
  }
#else
  robot_hw_sim_->readSim(sim_time_ros, ros::Duration(0.001));

  if (sim_period >= control_period_)
  {
    last_sim_time_ros_ = sim_time_ros;
    controller_manager_->update(sim_time_ros, sim_period);
  }

  robot_hw_sim_->writeSim(sim_time_ros, ros::Duration(0.001));
#endif
}

It seems as if the original code and the replacement I wrote should be roughly equivalent. My hypothesis is that the SetForce() calls in DefaultRobotHWSim::writeSim() affect Gazebo's current time step only. However, I've found no SetForce() documentation that describes that behavior.

For the moment, I'm going to refrain from setting controlPeriod in my URDF file, so readSim(), update, and writeSim() will be called during each Gazebo time step. I'm posting this issue in case someone wants to investigate it.

The "Delete Model" command is not working from this tutorial: http://gazebosim.org/wiki/Tutorials/1.9/ROS_Communication_with_Gazebo .

When you run

rosservice call gazebo/delete_model '{model_name: rrbot1}'

And rrbot1 does exist, a segfault occurs:

DEBUG ros.gazebo_ros: Waiting for model deletion (rrbot)
Segmentation fault (core dumped)
/home/dave/ros/ws_gazebo/src/gazebo_ros_pkgs/gazebo_ros/scripts/gazebo: 25: kill: invalid signal number or name: SIGINT

Running the command rosrun gazebo_ros gazebo crashes out with the following error:

Gazebo multi-robot simulator, version 1.8.6
Copyright (C) 2013 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

Msg Waiting for master.Gazebo multi-robot simulator, version 1.8.6
Copyright (C) 2013 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[ INFO] [1371154330.968053918]: Finished loading Gazebo ROS API Plugin.
Msg Waiting for master[ INFO] [1371154330.968401059]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...

Msg Connected to gazebo master @ http://127.0.0.1:11345
Msg Publicized address: 128.83.122.150
[ INFO] [1371154331.436120622]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[ INFO] [1371154331.488619679]: Physics dynamic reconfigure ready.

Msg Connected to gazebo master @ http://127.0.0.1:11345
Msg Publicized address: 128.83.122.150
Exception [RenderEngine.cc:579] unable to find OpenGL rendering system. OGRE is probably installed incorrectly. Double check the OGRE cmake output, and make sure OpenGL is enabled.

Error [Rendering.cc:38] Failed to load the Rendering engine subsystem
unable to find OpenGL rendering system. OGRE is probably installed incorrectly. Double check the OGRE cmake output, and make sure OpenGL is enabled.
Warning [ModelDatabase.cc:117] GAZEBO_MODEL_DATABASE_URI not set
Warning [ModelDatabase.cc:117] GAZEBO_MODEL_DATABASE_URI not set
Warning [ModelDatabase.cc:202] Unable to connect to model database using [//database.config]. Only locally installed models will be available.
Error [parser.cc:99] Unable to load file[]
Warning [parser.cc:499] XML Attribute[version] in element[sdf] not defined in SDF, ignoring.
Error [parser.cc:719] XML Element[model], child of element[sdf] not defined in SDF. Ignoring.[]
Warning [parser.cc:427] Unable to parse sdf element[]
Error [parser.cc:337] parse as sdf version 1.4 failed, should try to parse as old deprecated format
Error [SDF.cc:1648] Unable to parse sdf string[<sdf version ='1.4'><model name='building_template_model'><pose>0 0 0.0 0 0 0</pose><link name ='link'><collision name ='collision'><geometry><box><size>1.0 1.0 1.0</size></box></geometry></collision><visual name ='visual'><pose>0 0 0.0 0 0 0</pose><geometry><box><size>1.0 1.0 1.0</size></box></geometry><material><script><uri>file://media/materials/scripts/gazebo.material</uri><name>Gazebo/Grey</name></script></material></visual></link><static>true</static></model></sdf>]
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Error [WindowManager.cc:96]  Unable to create the rendering window
Exception [WindowManager.cc:103] Unable to create the rendering window


Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'gazebo::common::Exception'
Aborted (core dumped)

I haven't debugged the OpenGL issues yet. Gazebo 1.5 built through simulator-gazebo 1.7.12 seems to be working fine on this machine. However, I can't seem to figure out the error regarding building_template_model. I am not even sure where that SDF is coming from. The following commands return nil for me:

piyushk@zoidberg:~$ locate *.sdf | xargs grep "building_template"
grep: /nishome/piyushk/Downloads/model: No such file or directory
grep: (1).sdf: No such file or directory
piyushk@zoidberg:~$ locate *.model | xargs grep "building_template"

I am not sure if this is a bug or if I just misunderstood the concept of the different NodeHandles in ros_control: According to the documentation of gazebo_ros_control in the gazebosim.org wiki it is possible to specify the namespace of the controller manager via the robotNamespace parameter in sdf. If the tag is omitted, the controller manager should use the robot name as default value.

Unfortunately this tag has a special meaning when spawning robots using the spawn_model service (or indirectly via rosrun gazebo_ros spawn_model), as the service server implemented in gazebo_ros_api_plugin adds this tag with the namespace in which the spawn_model tool was run if it is unset, which makes sense when you want to spawn multiple models in different namespaces. As a consequence, it is not possible to make the gazebo_ros_control plugin use the default value (the robot name) without having to explicitly specify the robot name in the plugin parameters in contrast to the documentation. I also do not want to do that as the robot name is also set by the spawn_model service.

[ INFO] [1381528658.519866239, 58.905000000]: Loading gazebo_ros_control plugin
[ INFO] [1381528658.520003048, 58.905000000]: Starting gazebo_ros_control plugin in namespace: /

Would it be possible to add an additional controlNamespace configuration tag and append its value to the robotNamespace? Instead of the robotNamespace the controlNamespace parameter could then have the robot name as a default value, independent of the robot namespace.

The gazebo_ros_laser plugin doesn't include the tf prefix when resolving frame names for topic messages headers.

In my simulated robot, a laser scanner is mounted in front of the base and is called with the code

<plugin name="gazebo_ros_${name}_controller" 
  filename="libgazebo_ros_laser.so">
                        [...]
                        <topicName>scan_front</topicName>
                        <frameName>laser_scanner</frameName>
                        <interface:laser name="gazebo_ros_${name}_iface" />
                    </plugin>

I set the tf_prefix parameter in the corresponding launch file, but when I inspect the published topic with rostopic echo scan_front | more I only get the frame name I specify without the prefix. Unfortunately this cause problems with other packages that expect to see the full resolved name.

$ rostopic echo /youbot/scan_front | more
header: 
  seq: 0
  stamp: 
    secs: 14
    nsecs: 614000000
  frame_id: laser_scanner

On the other hand, the gazebo_ros_planar_move plugin correctly use tf_prefix when resolving frame names.

$ rostopic echo /youbot/odom | more
header: 
  seq: 10298
  stamp: 
    secs: 525
    nsecs: 715000000
  frame_id: youbot/odom

Plugin currently publishes sensor_msgs/PointCloud. Would be nice to change it to PointCloud2 as it's more widely used.