Gazebo resources: Tutorials | Q&A | Documentation | Blog

Python bindings for Gazebo/Ignition

#1

Hey folks, so python bindings for Gazebo are something I’ve considered for a long time now. Usually this comes up in the context of I have a ros python node that I want to interact with gazebo transport, but just recently I had another case where I have python scripts that I want to spin up and manage many instances of gazebo simulations and having bindings would be much better than using the subprocess module. A third possible motivation would be making it easier to teach people how to use the gazebo APIs.

I’ve been using pybind11 recently for some of my own C++ code and it’s quite simple to use.

I’m wondering if there are enough use cases or general interest in this? Has this been discussed at all within Open Robotics?

1 Like
#2

A ruby interface using swig was added to ignition-math:

I think we could add a python interface in a similar way?

This is something we are interested in but haven’t been actively pursuing at the moment.

#3

I don’t have any experience with tools that do it automatically (swig?) but I wouldn’t be surprised if they existed for python too. My approach has been to expose whatever I need to expose by hand. OMPL I believe generates all the bindings automatically so that could be a thing to look at.

I know Nate really likes Ruby, but I’ve always felt it was a weird choice since I’ve never heard of it used for anything in robotics. Do you know of anyone outside of open robotics using the Ruby bindings or expressing interest in them?

#4

I believe swig supports python too, so I think the same approach that we’ve used for ruby could work for python too.

#5

I am looking forward to having official ignition bindings, it would be really a great addition. Using external processes with transport is a sound solution, but many application might be limited if they have to rely to socket-based connections.

I have recently worked towards this direction for a project I’m developing and I can share my experience. Swig is one of the only mature solution that provide multiple languages support, and it was the natural choice despite I only currently need Python. I didn’t face many issues in the process, but instead of binding directly the Ignition Gazebo public APIs, I wrapped the simulator in a C++ wrapper, and then exposed the wrapper to Python with Swig. In this way I could configure the simulator in C++ using its native language and then expose to Python only a very high-level interface. This choice was also related to the fact that Ignition uses heavily C++17 and there is no support of this standard in Swig (e.g. std::optional, widely used in ignition robotics). I don’t think is very demanding developing new typemaps for the missing features, but it goes beyond the scope of my work for the time being.

If you want to have a look to the development status and have an example from where to start, have a look to robotology/gym-ignition, and particularly GazeboWrapper.

#6

I’m not sure if it’s the thing you need, but I’m maintaining a small library for my project here: https://github.com/ci-group/pygazebo/tree/py2to3 (py2to3 branch)

it’s a library to communicate with gazebo via protobuf messages. It’s rough and I would like to improve it, but it works.

#7

One of the main use cases I have is running a number of gazebo instances, and so I would actually want the ability to start gzserver/gzclient executables, manage them, etc… so just a messaing API would not quite do it for that scenario. But still a useful thing to have. Like Diego said, making bindings for ignition/gazebo would be the more complete solution.

#8

Another project that might be quite interesting as a Swig alternative is Microsoft/xlang (FAQ). I do not have direct experience with it nor I saw in the past any real example, but it definitely worth a look.

#9

Considering classic gazebo and ignition transport, I remember I read that the developers of gym-gazebo2 (paper) claim they have network segmentation to allow multiple simulator instances. I do not know exactly how port names are affected by it, but @portaloffreedom library might be useful in this setup if it can interface smoothly with it.

#10

1 - I confirm that I’m actually running multiple instances gazebo at the same time, being able to communicate to them from the same python script at the same time.
2 - I just update the library to use python3 and asyncio, for clearer and more modern code. https://github.com/ci-group/pygazebo (master branch)

#11

@portaloffreedom Nice work. Bwt for readers not very familiar with Gazebo I would like to point out that your library will not work (yet?) with Ignition Gazebo as the OP was asking.

For a very simple example on Ignition Gazebo you can refer to joint_controller.sdf.