Gazebo classic. For the latest version, see https://github.com/gazebosim/gz-sim
Home Page: http://classic.gazebosim.org/
License: Other
Note
A new version of Gazebo (formerly known as Ignition) is now available. Please visit https://gazebosim.org or https://github.com/gazebosim/gz-sim to learn more.
This is the Gazebo Classic simulator. Gazebo simulates multiple robots in a 3D environment, with extensive dynamic interaction between objects.
Get started at
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
Added in capability to resize the side panel on the GUI.
Original report (archived issue) by Thomas de Candia (Bitbucket: tdecandia).
Dear Gazebo Development Team,
I am trying to start the gazebo gui with:
roslaunch gazebo_worlds empty_world.launch
It used to work a month ago, but I have recently updated some packages on my computer and since then, it keeps crashing on start up.
I have the following config:
OS: Ubuntu 12.04, 64 bit
Kernel: 3.2.0-30-generic x86_64 GNU/Linux
Graphic Card: Advanced Micro Devices [AMD] nee ATI Whistler [AMD Radeon HD 6600M Series]
Graphic Card Driver: fglrx_pci
Simulator Gazebo Version: 1.6.16
Here is the gdb output with the back trace at the end:
(gdb) run
Starting program: /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/bin/gzclient
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Gazebo multi-robot simulator, version 1.0.2
Copyright (C) 2011 Nate Koenig, John Hsu, Andrew Howard, and contributors.
Released under the Apache 2 License.
http://gazebosim.org
[New Thread 0x7fffeb890700 (LWP 16505)]
Msg Waiting for master
Msg Connected to gazebo master @ http://localhost:11345
[New Thread 0x7fffeae82700 (LWP 16506)]
[New Thread 0x7fffdbfff700 (LWP 16507)]
[New Thread 0x7fffd37fe700 (LWP 16508)]
[New Thread 0x7fffdb7fe700 (LWP 16509)]
[New Thread 0x7fffdaffd700 (LWP 16510)]
[New Thread 0x7fffda7fc700 (LWP 16511)]
[New Thread 0x7fffd9ffb700 (LWP 16512)]
[New Thread 0x7fffd97fa700 (LWP 16513)]
[New Thread 0x7fffd8ff9700 (LWP 16514)]
[New Thread 0x7fffae2d4700 (LWP 16515)]
[New Thread 0x7fffadad3700 (LWP 16516)]
[New Thread 0x7fffa7fff700 (LWP 16517)]
Program received signal SIGSEGV, Segmentation fault.
0x00007fffa6d7b494 in DBusMenuExporter::setStatus(QString const&) () from /usr/lib/x86_64-linux-gnu/libdbusmenu-qt.so.2
(gdb) bt
#0 0x00007fffa6d7b494 in DBusMenuExporter::setStatus(QString const&) () from /usr/lib/x86_64-linux-gnu/libdbusmenu-qt.so.2
#1 0x00007ffff5e07566 in QFactoryLoader::instance(QString const&) const () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2 0x00007ffff63efd22 in QIcon::addFile(QString const&, QSize const&, QIcon::Mode, QIcon::State) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#3 0x00007ffff63f005a in QIcon::QIcon(QString const&) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#4 0x000000000048dd7a in gazebo::gui::MainWindow::MainWindow() ()
#5 0x0000000000481c06 in gazebo::gui::load() ()
#6 0x0000000000482945 in gazebo::gui::run(int, char**) ()
#7 0x000000000047aeb9 in main ()
(gdb)
Thanks for you help.
Thomas
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
No GAZEBO_PLUGIN_PATH:
{{{
cd build
GAZEBO_RESOURCE_PATH=pwd/../ ./test/regression/common
[==========] Running 11 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 11 tests from CommonTest
[ RUN ] CommonTest.Image
Error [Image.cc:141] Unable to open image file[/file/shouldn/never/exist.png]
[ OK ] CommonTest.Image (48 ms)
[ RUN ] CommonTest.Paths
Segmentation fault (core dumped)
}}}
Arbitrary GAZEBO_PLUGIN_PATH:
{{{
cd build
GAZEBO_PLUGIN_PATH=/foobar GAZEBO_RESOURCE_PATH=pwd/../ ./test/regression/common
(everything works)
}}}
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
The reset button in the time panel makes the model fall apart if pressed multiple times.
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
I am on r8d5b7a4706ff with ogre 1.8.0 compiled from source.
starting gzserver works fine, but starting gzclient produces the following errors:
{{{
(gdb) bt
#0 0x00007ffff793e075 in boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_serviceboost::asio::ip::tcp >::close() () from /home/hsu/local/lib/libgazebo_transport.so.1
#1 0x00007ffff7937bf1 in gazebo::transport::Connection::OnConnect(boost::system::error_code const&, boost::asio::ip::basic_resolver_iteratorboost::asio::ip::tcp) () from /home/hsu/local/lib/libgazebo_transport.so.1
#2 0x00007ffff7940ebd in boost::asio::detail::reactive_socket_connect_op<boost::_bi::bind_t<void, boost::_mfi::mf2<void, gazebo::transport::Connection, boost::system::error_code const&, boost::asio::ip::basic_resolver_iteratorboost::asio::ip::tcp >, boost::_bi::list3<boost::_bi::valuegazebo::transport::Connection*, boost::arg<1> ()(), boost::_bi::value<boost::asio::ip::basic_resolver_iteratorboost::asio::ip::tcp > > > >::do_complete(boost::asio::detail::task_io_service, boost::asio::detail::task_io_service_operation*, boost::system::error_code, unsigned long) () from /home/hsu/local/lib/libgazebo_transport.so.1
#3 0x00007ffff7934e23 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
from /home/hsu/local/lib/libgazebo_transport.so.1
#4 0x00007ffff7935165 in boost::asio::io_service::run() () from /home/hsu/local/lib/libgazebo_transport.so.1
#5 0x00007ffff39e3ce9 in thread_proxy () from /usr/lib/libboost_thread.so.1.46.1
#6 0x00007ffff5a6ae9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007ffff41f04bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x0000000000000000 in ?? ()
(gdb)
}}}
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
Before shipping, we should disable debug output that happens inserting a URDF model.
E.g., insert camhand from drcsim:
Warning [parser.cc:375] Gazebo SDF has no <gazebo> element in file[/home/osrf/tmp/install/share/drcsim-0.1.0/models/camhand/model.sdf]
Debug: No 'default' collision group for Link 'world'
Debug: setting link 'world' material
Debug: successfully added a new link 'world'
Debug: successfully added a new visual group name 'default'
Debug: successfully added a new visual under group name 'default'
Debug: successfully added a new collision group name 'default'
Debug: successfully added a new collision under group name 'default'
Debug: setting link 'right_palm' material
Debug: link 'right_palm' material 'right_camhand_skin' defined in Visual.
Debug: successfully added a new link 'right_palm'
Debug: No 'default' collision group for Link 'right_f0_base'
Debug: setting link 'right_f0_base' material
Debug: successfully added a new link 'right_f0_base'
Debug: No 'default' collision group for Link 'right_f0_fixed_accel'
Debug: setting link 'right_f0_fixed_accel' material
Debug: successfully added a new link 'right_f0_fixed_accel'
Debug: successfully added a new visual group name 'default'
Debug: successfully added a new visual under group name 'default'
Debug: successfully added a new collision group name 'default'
Debug: successfully added a new collision under group name 'default'
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
Sometimes (race condition), while starting gzserver and gzclient at the same time, gzclient will display partial model loaded in gzserver. Starting another instance of gzclient will show the complete model. To reproduce (could take many tries), try loading:
{{{
gzserver pr2.world & -- ; gzclient &
}}}
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
If a request for model://foo is made and the current working directory contains a file or directory called foo, then ModelDatabase::GetModelPath() will end up looking for $PWD/foo/manifest.xml.
An easy demonstration of this problem is the pr2 test: it's a binary called pr2 and it requests model://pr2. If you run this test from within build/test/regression, it will fail. Run it from somewhere else (some directory not containing a file or directory called pr2), it will succeed. This is why the test fails under make test; ctest is running each test from the directory where it was compiled to.
I'm not sure what the right behavior here is. If you want people to shortcut the environment variables to refer to local models via model://relative/path/to/something, then there should at least be a check for whether that path, if it exists, is a directory. But even with that check, I think that having different model-lookup behavior depending on the value of PWD will be confusing. Better to force people to use GAZEBO_MODEL_PATH.
Marking critical because it's preventing a clean test report from Jenkins.
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
The original report had attachments: Screenshot from 2012-08-06 17:19:18.png
See attached. Running gazebo from dev branch, visualized depth camera data in rviz. Running on a vesa frame buffer emulated gpu with direct rendering enabled (i.e. my macbookpro 10,1 with ubuntu precise)
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
There is a problem in Entity::UpdatePhysicsPose with one of the entities:
one of the children has an invalid type (LINK but not COLLISION)
This is probably due to an error in the world file.
Here's the message on the console:
Msg Waiting for master.Msg Waiting for master
Msg Connected to gazebo master @ http://localhost:11345
Warning [RenderEngine.cc:381] Unable to load Ogre Plugin[/usr/lib/x86_64-linux-gnu/OGRE-1.7.4/Plugin_CgProgramManager.so]Heightmaps(Terrain) will not display properly.You'll need to install Ogre3d from source.Please visit www.ogre3d.org.
Msg Connected to gazebo master @ http://localhost:11345
Exception [Entity.cc:450] Invalid type[1088]
terminate called after throwing an instance of 'gazebo::common::Exception'
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
directory media/models is not created by default under GAZEBO_RESOURCE_PATH
The tutorial implies it should be there
I've updated the tutorial to warn that it should be created, but I'm creating an issue in case it should be created as part of the installation
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
To start with, deb-build should upload to gazebosim.org somewhere. Waiting on SSH key installation.
After that, deb-build should dput files into proper repositories.
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
We have to run cmake successfully before make doc. This means that we need to install everything that cmake requires (ogre, qt, etc.).
It should be possible to make doc with just doxygen (and maybe a couple of other things) installed.
Right now, this only matters for the CI job that builds docs, and it doesn't matter very much even there.
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
/home/hugo/code/osrf_tutorials/gazebo_animate_pose/animate_pose.cc:10:3: error: invalid use of incomplete type ‘struct gazebo::ModelPlugin’
/usr/local/include/gazebo-1.0.2/gazebo/common/CommonTypes.hh:54:9: error: forward declaration of ‘struct gazebo::ModelPlugin’
/home/hugo/code/osrf_tutorials/gazebo_animate_pose/animate_pose.cc:32:1: error: expected constructor, destructor, or type conversion before ‘}’ token
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
Causes a segault.
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
I'm usually testing by running gazebo. If the client crashes, the next time I run gazebo, I get a segfault. Then the next time I get
Exception [Master.cc:69] Unable to start server[Address already in use]
Then I'm killalling my way around, which is not pleasant.
We should clean this up. I'm happy to help.
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
Source packages (*.dsc) are not signed. They should be. Will require creating PGP keys for use by deb-build user.
Not strictly needed until we expect somebody who checks such things (e.g., Ubuntu) to consume our source packages as input.
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
see [[https://github.com/osrf/gazebo/blob/7bf73ebff5f62f1c71cc1bc6f27f6f7d1e378f6f/gazebo/physics/ode/ODEJoint.cc]]
lines 94-100, a parameter equivalent to provideFeedback need to be created, and following block should be re-eanbled:
{{{
#!c++
// TODO: reimplement
/*if (**this->provideFeedbackP)
{
this->feedback = new dJointFeedback;
dJointSetFeedback(this->jointId, this->feedback);
}
*/
}}}
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
feature broken in transition to 1.x.x, need to recover it.
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
The original report had attachments: mesh_import_1.2.0.zip
launch gazebo
import mesh
select duck.dae
left click on the grid
There are two ducks, (but only one is rocking)
see attachement files
Original report (archived issue) by DavidB (Bitbucket: dbworth).
Hi, is this a bug?
I've created a urdf.xacro file with a robot model. This first link is an empty dummy link called "base_link":
{{{
}}}
which is connected via a fixed joint to the next link, which has visual/collision/inertial properties.
When I try to spawn this model in Gazebo using the standard launch file syntax from the tutorial, it fails with an error.
Below is the last part of the console messages:
{{{
Msg Waiting for master.[ INFO] [1343134213.889006519]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
Msg Waiting for master
Msg Connected to gazebo master @ http://localhost:11345
Msg Connected to gazebo master @ http://localhost:11345
waiting for service spawn_urdf_model
gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr::operator->() const [with T = urdf::Inertial]: Assertion `px != 0' failed.
Aborted (core dumped)
Service call failed: transport error completing service call: unable to receive data from sender, check sender's logs for details
[empty_world_server-2] process has died [pid 14231, exit code 134, cmd /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/scripts/gazebo /home/username/ros_workspace/hubo/hubo_sim_gazebo/worlds/empty.world __name:=empty_world_server __log:=/home/username/.ros/log/19bf9996-d58e-11e1-b234-5c260a0c5681/empty_world_server-2.log].
log file: /home/username/.ros/log/19bf9996-d58e-11e1-b234-5c260a0c5681/empty_world_server-2*.log
}}}
The error points to an inertial tag, and a ROS Answers post suggests something similar.
Adding some inertial values to the base_link fixes the problem and Gazebo starts and spawns the model:
{{{
}}}Other child links without inertial properties are just ignored, like they should be:
{{{
[ WARN] [1343134922.979297087]: urdf2gazebo: link(Tool_link) has no inertia, parent joint(Tool_fixed_joint) is ignored.
[ WARN] [1343134922.979437714]: urdf2gazebo: link(Tool_link) has no inertia, not modeled in gazebo.
}}}
So is this a bug or a feature?
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
Has too many operators.
multiplication and division operators should only be available for double
#!c++
/////////////////////////////////////////////////
const Time &Time::operator *=(const Time &_time)
{
this->sec *= _time.sec;
this->nsec *= _time.nsec;
this->Correct();
return *this;
}
This is confusing use of multiplication operator. I would expect an implementation that looks like this:
#!c++
const Time &Time::operator *=(const Time &_time)
{
double t = this->Double() * _time.Double();
this->Set(t);
return *this;
}
also... why can't GetWallTime return Time instead of a Time& ?
#!c++
const Time &Time::GetWallTime()
This could lead to weird behavior if used like so:
#!c++
const Time& t = Time::GetWallTime();
// do something with t.sec ...
// t.sec may have changed
Original report (archived issue) by jagielka (Bitbucket: jagielka).
When using <sensor:ray name="laser"> and update rate is quite short you receive lots of warnings:
Warning [RaySensor.cc:206] ranges not constructed yet (zero sized)
Quick solution for this issue is to move the locking mechanism before reading laserMsg.ranges in function RaySensor::GetRange
{{{
#!c++
double RaySensor::GetRange(int _index)
{
boost::mutex::scoped_lock(*this->mutex);
if (this->laserMsg.ranges_size() == 0)
{
gzwarn << "ranges not constructed yet (zero sized)\n";
return 0.0;
}
if (_index < 0 || _index >= this->laserMsg.ranges_size())
{
gzerr << "Invalid range index[" << _index << "]\n";
return 0.0;
}
// Move locking mechanism to the beginning of the function
// boost::mutex::scoped_lock(*this->mutex);
return this->laserMsg.ranges(_index);
}
}}}
Original report (archived issue) by Mihai Emanuel Dolha (Bitbucket: mdolha).
Setting link self_collide to true doesn't enable collision between the links of a model.
This is caused by the fact that on link creation in ODEPhysics.cc line 404 the model's spaceId is set for the link. Later when self_collide is processed for the link in ODELink::SetSelfCollide a new spaceId is created for the link only if the link doesn't have a spaceId assigned already, but this is not the case.
Original report (archived issue) by Anonymous.
allow user to set either update_rate for physics, or maximum real-time factor (update_rate * dt) from menu --> world dialog.
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
The original report had attachments: Bot.lxfml
Lego Digital Designer can export models of NXT-based robots in the attached format. Check whether we can easily convert them to URDF/SDF.
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
I've been using gazebo through ROS - electric and now fuerte. I used the gazebo_pr2 stack as a starting point for generating URDF files.
In Electric all cameras (stereo and mono) use gazebo_ros_camera to simulate data and the left/right wide_stereo camera timestamps created were in sync. That's all fine and my stereo vision algorithms work just fine using the synchronized image pairs.
In Fuerte all cameras (stereo and mono) use gazebo_ros_depth_camera to simulate data (with gazebo-1.0.2). However the left/right wide_stereo camera timestamps are not synchronised - so I can't process them.
Have you come across this issue or can you replicate it?
The code between these plugins is very different and I assume generating simulated stereo data is more complicated than just adding to mono cameras to gazebo.
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
[[http://gazebosim.org/wiki/quick_start|quick start]] page is empty.
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
Timed-out tests currently just don't show up in the report. Should dig into that tool that Ken wrote to synthesize failed test reports.
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
The binary deb-build should include ros-fuerte-urdfdom and friends, as well as ros-fuerte-visualization-common (to get ROS's OGRE, which include CG support).
Be sure to update Build-Depends and Depends in debian/control.
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
remove cut and paste for path operation
Original report (archived issue) by ugocupcic (Bitbucket: ugocupcic).
The original report had attachments: contactsensor.patch
from: http://answers.ros.org/question/41765/contactsensor-in-gazebofuerte/
I am trying to get the Shadow-hand running in Fuerte, both the real one (EtherCAT) and the simulated one. For grasp planning, information about contacts/collision is obviously kind of important, and the Shadow hand simulation URDF model includes Gazebo bumpers (contact sensors) on all fingers. The sensors were working fine in Electric, and we got nice approximated wrenches from Gazebo.
In Fuerte, everything compiles, and the "deprecated" parser looks like it is doing the right thing of mapping the urdf sensor:contact tag to the conversions as required by newest SDF.
Problem is, the first subscriber to one of the bumper topics triggers a ContactSensor.GetContacts() call, which in turn detects that the "contacts" data-structure is read but was NEVER initialized...
Please don't blaim this on the Shadow-Hand stack. We also tried using the Gazebo contact-sensors on the PR2 gripper (vanilla Fuerte install on Ubuntu 12.04), and the same error message from "ContactSensor.cc:237" results. Simply broken in Fuerte, and possibly never tested before?
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
Hi I found a thread in the archive with an unresolved issue concerning libpng.
I have a similar problem on my ubuntu distribution, as I have multiple libpng versions installed.
I tried installing from debian packages, and compiling manually.
Then I noticed that the compiler and linker refers to one version of libPNG, but at runtime, another library is found.
I forced the correct version to be preloaded before starting the client, which circumvents the issue.
usage:
LD_PRELOAD=PATH_TO_LIBRARY.so programname
in my case it is:
LD_PRELOAD=/usr/lib/i386-linux-gnu/libpng.so gzclient
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
When the connection to the server is lost, a notification should appear on the GUI. It should also try reconnecting, or allow the user to select a different server, or even restart the server.
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
There are certainly some things missing. A candidate rule to apply: for each foo-dev that appears in Build-Depends, foo should appear in Depends.
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
The gui mouse selection is really bad. Fix it. Use a color selection buffer like normal people.
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
SystemPaths::GetOgrePaths(), SystemPaths::GetGazeboPaths(), SystemPaths::GetPluginPaths() calls corresponding Update*Paths() before returning the list of stored paths, this will always use the paths set by environmental variables even if the user use SystemPaths::Set*Paths(...) call to specify custom paths. Instead SystemPaths::Update*Paths() should be called only at start-up.
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
gzsdf -h
Doesn't list the convert option.
Original report (archived issue) by Erik Stoltenborg (Bitbucket: erikstoltenborg).
The original report had attachments: link.sdf
Link.sdf contains a small trivial error which make it impossible to set the link damping from a world file.
Should be:
The new file can be found in the attachment.
Regards,
Erik Stoltenborg
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
Hello Nate,
I found another bug.
I want to launch the world with a specific point of view. This is the code:
<gui fullscreen="false">
<camera name="mi_cam">
<origin pose= "10 0 2 0 0 3.14"/>
</camera>
</gui>
Ok, the start of the simulation is good but when I want to go around the world, it seems like the view is inside the yellow point of the orbit view control, I have to go back and now I can move around the world. I have better performance with FPS view control and I have to change it again and again when start simulations. Is there any form to begin with FSP instead of orbit?
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
While bringing up a Jenkins build, I encountered this compile error:
/var/lib/jenkins/jobs/gazebo-dev-devel-precise-amd64/workspace/gazebo/gazebo/common/ModelDatabase.cc:21:20: fatal error: libtar.h: No such file or directory
Seems like there should be a test for it during the CMake configure step, to push the failure earlier.
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
to reproduce, try sdf/worlds/simple_gripper.world in rev a60e975. Hitting reset world to see ray visualization stop.
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
Here's the value of my GAZEBO_RESOURCE_PATH
GAZEBO_RESOURCE_PATH=/home/hugo/local/share/gazebo-1.2.0:/home/hugo/local/share/gazebo_m
here's the content of
/home/hugo/local/share/gazebo-1.2.0/media/models/
sim_arm1.model
sim_arm2.model
sim_arm3.model
simple_arm_v1.model
The gazebo menu Models/models/ only contains ground_plane
Original report (archived issue) by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).
The pr2 regression test is apparently failing because the data offered by http://gazebosim.org/gazebo_models is out of date. To wit:
build$ ./test/regression/pr2
Error [ModelDatabase.cc:140] No <database> tag in the model database manifest.xml found here[http://gazebosim.org/gazebo_models/]
Error [ModelDatabase.cc:221] Unable to download model[model://pr2]
Error [ModelDatabase.cc:392] Invalid model manifest file[/manifest.xml]
Error [World.cc:1175] Unable to read sdf file.
/home/osrf/tmp/gazebo/test/regression/pr2.cc:33: Failure
Expected: (i) < (200), actual: 200 vs 200
/home/osrf/tmp/gazebo/test/regression/pr2.cc:42: Failure
Value of: sensor
Actual: false
Expected: true
/home/osrf/tmp/gazebo/test/regression/pr2.cc:46: Failure
Value of: camSensor
Actual: false
Expected: true
Segmentation fault (core dumped)
If I run with an override of the model database pointing to a recent checkout of gazebo_models, then the test passes:
build$ GAZEBO_MODEL_PATH=~/tmp/gazebo_models ./test/regression/pr2
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from PR2Test
[ RUN ] PR2Test.Load
Gazebo multi-robot simulator, version 1.2.0
Copyright (C) 2011 Nate Koenig, John Hsu, and contributors.
Released under the Apache 2 License.
http://gazebosim.org
Msg Waiting for master
Msg Connected to gazebo master @ http://localhost:11345
[ OK ] PR2Test.Load (23255 ms)
[----------] 1 test from PR2Test (23255 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (23255 ms total)
[ PASSED ] 1 test.
Perhaps something needs to be updated/uploaded?
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
A single pc should be able to run multiple instances of the server. The GUI should have a panel that displays the available servers, and the available worlds in each.
Original report (archived issue) by Morgan Quigley (Bitbucket: Morgan Quigley, GitHub: codebot).
using the 1.2.0 deb:
I tried doing this under gdb, but the backtrace doesn't seem to find any symbols in gazebo other than gazebo::gui::run() , then QCoreApplication::exec(), then QEventLoop::exec(), so I assume the interesting things are happening in other thread(s), but I wasn't sure which to backtrace.
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
physics.cc test fails ocassionally when it does
world->SetState(someState);
EXPECT_TRUE(world->GetState().GetModelState("model") == someState);
The right thing to do is to make SetState wait on a condition such that all other state updates (i.e. from physics) have finished.
Original report (archived issue) by Hugo Boyer (Bitbucket: hugomatic, GitHub: hugomatic).
The doc says that NULL is returned if the index is wrong, but the implementation uses opertator [] which doesn't check.
http://en.cppreference.com/w/cpp/container/vector/operator_at
Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).
can be anywhere from 10 to 50% slower than expected (see [[http://answers.ros.org/question/43960/publishing-rate-of-gazebo-sensor-plugins-broken-on-fuerte/ | this thread]]). This is probably because SensorManger::Update() calls image sensor updates and ray sensor updates serially. Image rendering is dictated by GPU transport rates, so it's a good idea to split the two up into separate threads.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.