Home | Tutorials | Wiki | Issues
Ask Your Question
0

Single stepping - ways to speed it up?

asked 2017-01-18 11:14:32 -0600

GlenH gravatar image

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?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-01-20 17:37:57 -0600

hugomatic gravatar image

If I understand your architecture correctly, your Simulink process sends a world control over the network in between each step.

This could add a lot of networking overhead and may slow down the most critical simulation loop, and leave little time for simulation.

  • 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.

  • Can you generate code from Simulink and run it from inside a Gazebo plugin?

edit flag offensive delete link more

Comments

"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.

GlenH gravatar imageGlenH ( 2017-01-20 18:33:07 -0600 )edit

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.

GlenH gravatar imageGlenH ( 2017-01-20 18:33:23 -0600 )edit

"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.

GlenH gravatar imageGlenH ( 2017-01-20 18:33:39 -0600 )edit

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.

GlenH gravatar imageGlenH ( 2017-01-20 18:33:48 -0600 )edit

"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...

GlenH gravatar imageGlenH ( 2017-01-23 13:46:08 -0600 )edit

..., 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.

GlenH gravatar imageGlenH ( 2017-01-23 13:46:59 -0600 )edit

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.

GlenH gravatar imageGlenH ( 2017-01-23 14:41:48 -0600 )edit

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.

GlenH gravatar imageGlenH ( 2017-01-23 14:44:01 -0600 )edit
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2017-01-18 11:14:32 -0600

Seen: 1,546 times

Last updated: Jan 20 '17