Wrappers, tools and additional API's for using ROS with the Gazebo simulator. Formally simulator_gazebo stack, gazebo_pkgs is a meta package. Now Catkinized and works with the standalone Gazebo debian.
See Contribute page.
Wrappers, tools and additional API's for using ROS with Gazebo
Home Page: http://wiki.ros.org/gazebo_ros_pkgs
Wrappers, tools and additional API's for using ROS with the Gazebo simulator. Formally simulator_gazebo stack, gazebo_pkgs is a meta package. Now Catkinized and works with the standalone Gazebo debian.
See Contribute page.
RMF = Robot Modeling Format, Gazebo's rename of SDF
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.
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>
The GUI gets loaded by default when you run the gazebo script. This behavior is different from simulator-gazebo. Is this intended?
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?
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?
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
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.
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
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.
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"
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
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...
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?
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
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
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?
"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
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 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.
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.
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:
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).
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.
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.
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
Plugin currently publishes sensor_msgs/PointCloud. Would be nice to change it to PointCloud2 as it's more widely used.
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.
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]
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.
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.
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)
Currently only supports stereo cameras. Update documentation here when fixed:
http://gazebosim.org/wiki/Tutorials/1.9/ROS_Motor_and_Sensor_Plugins#Multicamera
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.
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.
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
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.
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?
Experimental: https://github.com/osrf/gazebo_ros_pkgs/blob/hydro-devel/gazebo_ros_control/src/ros_control_plugin.cpp#L306
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.
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!
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
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
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:
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.
They started as dirty duplicate code, need to consolidate and deprecate one of them.
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
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
PCL has been updated to 1.7 on shadow-fixed, breaking all plugins that used pointclouds. Is a patch required?
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>
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.