Gazebo | Ignition | Community
Ask Your Question

GlenH's profile - activity

2020-06-09 19:32:42 -0600 received badge  Famous Question (source)
2018-12-04 06:16:57 -0600 received badge  Famous Question (source)
2018-08-15 04:06:10 -0600 received badge  Famous Question (source)
2018-08-15 04:06:10 -0600 received badge  Notable Question (source)
2018-08-15 04:06:10 -0600 received badge  Popular Question (source)
2017-11-16 12:39:41 -0600 received badge  Notable Question (source)
2017-11-16 12:39:41 -0600 received badge  Popular Question (source)
2017-07-20 13:02:56 -0600 received badge  Famous Question (source)
2017-07-20 13:02:56 -0600 received badge  Notable Question (source)
2017-07-20 13:02:56 -0600 received badge  Popular Question (source)
2017-04-21 16:58:49 -0600 received badge  Notable Question (source)
2017-02-24 14:12:44 -0600 asked a question operating system agnostic plugin names

Is there a canonical solution to the problem of dynamic libraries having different extensions on Linux/OSX/Windows? There was a thread a while back that discussed it, but I couldn't find a resolution.

The problem is that on OSX, dynamic libraries are by default named libXXX.dylib, whereas on Linux they're On WIndows they're libXXX.dll.

When you specify libraries as plugins to a model, for instance, this makes the model architecture dependent. Not ideal.

Here's the original thread I found:

2017-02-13 10:04:59 -0600 received badge  Famous Question (source)
2017-02-06 21:28:32 -0600 received badge  Notable Question (source)
2017-02-03 10:03:17 -0600 received badge  Popular Question (source)
2017-02-02 11:16:20 -0600 asked a question Plugin order of execution

I'm trying to use Boost IPC mechanisms to communicate between an external application and some gazebo plugins. I'm not using the transport layer because speed is critical for my application, and IPC mechanisms give me about a 2x increase in simulation speed over using topics. We're going to be running many, many thousands of simulations inside a Monte Carlo method, and a 2x speed increase will potentially shave days off the running time.

Getting the IPC synchronization correct for this is tricky, of course, and I'm running into issues that have to do with the order in which the plugins are executed. My questions:

1) is there any way to specify an order of execution for multiple plugins?

2) Do the plugins execute in the same thread? If I (for instance) block on a mutex inside one plugin, will the entire simulation halt, or do the other plugins run?

2017-02-01 09:56:29 -0600 received badge  Popular Question (source)
2017-01-27 14:17:59 -0600 commented question Can topics messages get silently dropped?

Err... is this some new meaning of the word "ready" that I was not previously familiar with? Seems like if both the publisher and subscriber are ready, there should be some sort of presumption, if not a formal guarantee, that the traffic will go through. Under what conditions, specifically, are messages dropped on the floor? Is there any way to query whether this has happened?

2017-01-27 14:16:26 -0600 received badge  Enthusiast
2017-01-26 13:27:12 -0600 asked a question Can topics messages get silently dropped?

I'm trying to single-step gazebo from an outside application by issuing periodic world control messages.

About 4% of them appear to be ignored, not sent, or not received. Why? Aren't topics based on TCP sockets, which guarantee that no data gets lost?

2017-01-26 08:28:15 -0600 received badge  Famous Question (source)
2017-01-23 14:44:01 -0600 commented answer Single stepping - ways to speed it up?

With the model loaded but everything else the same - so only a world command topic is being passed through the transport layer - I can get the speed to about 2x slower than real time without any topic messages being lost. This implies that about 90% of my overhead is tied up in sending and receiving sensor topics. I'm also curious about how TCP-based topics messages could be getting silently dropped.

2017-01-23 14:41:48 -0600 commented answer Single stepping - ways to speed it up?

Attempting to be clever, I added a boost::thread:: sleep command inside my simulink code as a placeholder for a nonexistent sensor feedback topic, so I can run with no loaded model. Running this way I can get to just about real time.

2017-01-23 13:46:59 -0600 received badge  Commentator
2017-01-23 13:46:59 -0600 commented answer Single stepping - ways to speed it up?

..., because 1000 such topics should cause gazebo to step one full second, but it turns out that gazebo only steps forward about 0.2 seconds. Which means that 80% of the world command messages are getting lost. The upside, though, is that this happens nearly instantaneously.

2017-01-23 13:46:08 -0600 commented answer Single stepping - ways to speed it up?

"Do you know how fast you can do this in an empty world (without an models)?" Turns out that this doesn't really work the way I expected. Without the feedback - eg, without a topic being returned from gazebo to simulink reporting some sort of sensor data - Simulink goes ahead and issues 1000 world control topics as fast as it can, and most of those get silently dropped somewhere in the transport layer...

2017-01-23 01:35:40 -0600 received badge  Notable Question (source)
2017-01-20 18:33:48 -0600 commented answer Single stepping - ways to speed it up?

The update rate we want out of gazebo is between 1-2 kHz; but the World Control messages seem to get processed at only about 50 Hz. I think it should be possible to send protocol buffer-based messages through a TCP port at far faster rates than that, and I'm trying to figure out what else might be the cause of the slowdown.

2017-01-20 18:33:39 -0600 commented answer Single stepping - ways to speed it up?

"Can you generate code from Simulink and run it from inside a Gazebo plugin?" Unfortunately, that's probably not viable for us. We're using this to develop and validate a very complex set of control laws, most of which are written in Simulink. All of it eventually gets run on a SpeedGoat. Ultimately we'd like use the gazebo sim to run hardware-in-the-loop tests. So we really do need the Simulink code and gazebo to be separate.

2017-01-20 18:33:23 -0600 commented answer Single stepping - ways to speed it up?

If I strip this down to the absolute bare minimum - no sensors other than the joint angles reported by the links - then the system runs at around 20x slower than real time. "Do you know how fast you can do this in an empty world (without an models)? This could give you an idea of the maximum performance you can expect." I haven't tried that, but it's a good idea. I will work out the code and report back.

2017-01-20 18:33:07 -0600 commented answer Single stepping - ways to speed it up?

"If I understand your architecture correctly, your Simulink process sends a world control over the network in between each step." That's correct. In fact, I do a bit more: I first send a topic message containing new joint angles. Then I send a world control message. The plugins associated with the robot model have callbacks registered to the WorldUpdateEnd event,which generate topic messages containing the various sensor values at the end of the time step which get sent back to Simulink.

2017-01-20 18:20:08 -0600 received badge  Popular Question (source)
2017-01-18 11:14:32 -0600 asked a question Single stepping - ways to speed it up?

I'm trying to get gazebo and Simulink to play nicely together. The primary issue is that Simulink runs an integrator, gazebo also runs an integrator, and there's no obvious way to make sure the two are stepping in sync with each other.

So I'm starting gazebo paused (-u command line argument). I've written a Simulink S-function (essentially a C plugin to Simulink) that sends a world control command to gazebo that tells it to take a single, fixed-length time step. I've also written a gazebo plugin - a handful of plugins, actually - that respond to a topic message that originates inside Simulink with a dump of the current simulation state. Thus, as a (to Simulink) atomic action, I can get gazebo to single-step and then send a series of topics that report the full state to Simulink, before Simulink takes its next time step.

As long as the stepsize in gazebo and Simulink are fixed and consistent, this works like a charm. With one exception: it's DOG SLOW. it is about 100x slower than realtime.I've turned off alomst all collision checking, I've tried running headless, I've done everything else I can think of to speed it up. No dice.

The identical gazebo simulation, left on its own to free-run, runs faster than realtime. So clearly there's either something either in my topic exchange protocol or in the process of gazebo single stepping, that makes this really inefficient. It does not appear to be on the Simulink side, eg the Simulink code isn't that slow.

Any ideas?

2016-12-23 14:08:08 -0600 asked a question Shutting down listener reliably abort traps

I'm writing a simple robot plugin with a custom message and a standalone executable that listens for world_stats topics to get the time, calculates some joint angles, and sends them back to the plugin over a custom topic. This is mostly a mashup of the velodyne plugin tutorial plus the custom message tutorial.

The twist is that I'm trying to break out the "initialize gazebo transport", "calculate and send joint angles" and "shut everything down" functions out into separate function calls in a shared library.

This works very well until it comes time to shut down. At that point, after everything has executed and the thread exits, I get the following:

libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >: boost: mutex lock failed in pthread_mutex_lock: Invalid argument Abort trap: 6

I can make this entirely go away if I don't ever subscribe with a callback function to listen to the world_stats topic.

I've attached my code below. Any ideas what might be causing this?

#include "robot_lib.h"
extern "C" {

gazebo::transport::NodePtr node;
allegrodog_msgs::msgs::RobotSetAnglesRequest theta;
gazebo::msgs::WorldControl step;
gazebo::transport::PublisherPtr anglepub;
gazebo::transport::PublisherPtr step_cmd;
gazebo::transport::SubscriberPtr sub;
double __sim_gt;

void _cb(ConstWorldStatisticsPtr &_msg)
     gazebo::common::Time t;

   t = gazebo::msgs::Convert(_msg->sim_time());    
   __sim_gt = t.Double();

void initGazebo() {

 node = gazebo::transport::NodePtr(new gazebo::transport::Node());

 // This topic will let us issue gazebo single-step commands
 step_cmd = node->Advertise<gazebo::msgs::WorldControl>("/gazebo/default/world_control");

 // This topic will let us issue joint commands to the robot
 anglepub = node->Advertise<allegrodog_msgs::msgs::RobotSetAnglesRequest>("/gazebo/default/my_robot/set_angles");

 // Listen to Gazebo world_stats topic
 sub = node->Subscribe("/gazebo/default/world_stats", _cb);


void sendAnglesGazebo(double* jointpos) {


void shutdownGazebo() {
    std::cout << "Shut down\n";
2016-12-22 18:05:57 -0600 received badge  Student (source)
2016-12-22 17:48:13 -0600 commented question I can see some gazebo topics, but not all of them...

One potentially pertinent fact: Matlab links against a bunch of the same libraries gazebo does, including boost and protobuf. But Matlab's versions are typically a couple of versions older than gazebo's. When building my MEX file I have tried both dynamically linking to dylibs and statically linking to .a files. Neither one seems to make any difference, but it's possible that I'm not seeing a dependency somewhere.

2016-12-22 17:44:22 -0600 commented question I can see some gazebo topics, but not all of them...

Yep. Every last one of them. I can also issue a "system" command inside Matlab, which issues a shell command, eg system('\usr\local\bin\gz topic -l') and that *also* returns all of the topics.