Home | Tutorials | Wiki | Issues
Ask Your Question
0

Proper way of using Gazebo as a library (within a custom library)

asked 2017-08-09 15:52:17 -0500

hamzamerzic gravatar image

I would like to create a library from which I can get a world pointer of Gazebo. By looking at the examples shown here, it seems like there could be two ways to do it.

One way would be to use the class as the server, and load the world. In this case I noticed that the world behaves a lot differently than in the case of a plugin (e.g. by using a world plugin), when I control the world pointer. For example, Step doesn't do anything, and instead I have to use Run or RunBlocking. Also, I am having some issues, for example when spawning a model, the InsertModelFile function which doesn't do anything, along with some other differences in the way the world pointer operates. Nevertheless, this way seems quite convenient, but I am definitely missing something here, so I would be grateful if you could provide some pointers on how to make the world pointer behave in the same way as I would use the pointer within a plugin.

The other way that could work is by spawning gazebo externally and using the client library. In this case though, I am having issues obtaining and manipulating the world pointer (tried using gazebo::physics::get_world function). Is this possible to do this this way as well, and how?

Thanks!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2017-08-14 19:21:01 -0500

iche033 gravatar image

Does this example work? It uses RunBlocking underneath. You can then try and connect to the event::Events::ConnectWorldUpdateBegin events and do your processing in the callback function like in the plugins

edit flag offensive delete link more

Comments

I built on top of this example, so it does work, but my concerns are that step and insertModelFile world methods do not do anything. If I am manually stepping through the simulation, I don't need the events (but I am curious what spins the callbacks - is it the setupServer part that creates a spinning thread, or does RunBlocking handle it in the background?). Also, regarding the client case, do you have any idea why manipulating the world pointer from the client does not work? Thank you!

hamzamerzic gravatar imagehamzamerzic ( 2017-08-16 03:27:31 -0500 )edit

Also, I compared the performance of having a plugin and stepping through the simulation and using the library version, and the library version is more than two times slower. Also, to manipulate the world the plugin needs to subscribe to a bunch of topics, whose requests are sent from a different node (i.e. there is a lot of communication overhead), while for the library version I directly have access to world. Still cannot wrap my head around why world->Step(n) does not work...

hamzamerzic gravatar imagehamzamerzic ( 2017-08-16 06:20:53 -0500 )edit

the reason for doing stuff in the event callback is that it guarantees the work done in the main physics thread. Modifying the world outside of the physics thread may cause expected behavior. Back to what you're trying to achieve - You should be able to modify the world in a World plugin without publishing to topics. You get a pointer to the world in Load and can do things like InserModelFile: http://gazebosim.org/tutorials?tut=plugins_world

iche033 gravatar imageiche033 ( 2017-08-16 12:17:41 -0500 )edit

I know that, and I want to modify the world from Python code, so the way I am doing it now is I am wrapping C++ code in Python. I use the wrapped C++ class to communicate to a world plugin, and in the world plugin I directly edit the world. What I would like to do is directly wrap C++ code that can modify the world, and to do so I need to use gazebo as a library. And then the issues that I mentioned above start happening.

hamzamerzic gravatar imagehamzamerzic ( 2017-08-16 14:23:54 -0500 )edit
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2017-08-09 15:52:17 -0500

Seen: 17 times

Last updated: Aug 14