Bridge services

[chapulina]

Ignition offers several services. It would be good to bridge them directly to ROS (1 and 2) so users can do things like spawning entities directly from ROS.

[gezp]

Hi,I have some simple and rough work about it: https://github.com/gezp/ros_ign_gazebo_py

it's very useful to control ignition Gazebo (by service) with ROS , for example, resume and pasue Ignition Gazebo, create model,delete model and set pose of model.

In my case, I need control Ignition Gazebo with python, but ign-transport doesn't support python, so i use ROS as bridge with C++, and then i create ROS Client Node with python so that i can control ignition Gazebo with python.

by the way, before implementing bridge services, ros_ign_interfaces is necessary to provide ros msg,srv files related to ign-msgs , like EntityFactory.msg . i think this package should be considered currently, and this is my opinion, any discussions is welcome.

finally, this is a very useful function, i hope it can be implemented earlier.

[chapulina]

Hi @gezp , we're not currently planning to work on this, but we can review a pull request if you're willing to implement it.

[gezp]

I'm glad to contribute, but the New ROS Package ros_ign_interfaces is allowed to pull request?

In addition, I think ign_gazebo_manager.cpp (https://github.com/gezp/ros_ign_gazebo_py : bridge part services ) should be put in ros_ign_gazebo/src , and ign_gazebo_interface.py (ros client node for ign_gazebo_manager service, provide python interface )should be put in ros_ign_gazebo/ros_ign_gazebo (python package will be created).

I will do this work if it's ok.

[chapulina]

New ROS Package ros_ign_interfaces is allowed to pull request?

Yes, thanks! I think there's no way around it, we'll need to add some Ignition-specific ROS messages that aren't provided by other packages.

I considered maybe using gazebo_msgs, but those messages carry some Gazebo-classic concepts that I think we wouldn't want here.

I think ign_gazebo_manager.cpp (https://github.com/gezp/ros_ign_gazebo_py : bridge part services ) should be put in ros_ign_gazebo/src

I'm curious, why ros_ign_gazebo instead of ros_ign_bridge?

ign_gazebo_interface.py (ros client node for ign_gazebo_manager service, provide python interface )should be put in ros_ign_gazebo/ros_ign_gazebo

This sounds reasonable to me.

[gezp]

I'm curious, why ros_ign_gazebo instead of ros_ign_bridge?

because ros_ign_bridge currently provides a general topic's transfer between ROS and Ignition. and i don't find a way to provide a general service's transfer between ROS and Ignition.

ign_gazebo_manager(https://github.com/gezp/ros_ign_gazebo_py) provide a function to control Ignition Gazebo (create model, etc) in ROS, which is based on service's transfer , just like ros_ign_gazebo/src/create, this is why I want to put ign_gazebo_manager in ros_ign_gazebo/src.

[chapulina]

because ros_ign_bridge currently provides a general topic's transfer between ROS and Ignition. and i don't find a way to provide a general service's transfer between ROS and Ignition.

Oh, thank you for the clarification, I thought that your solution would be generic.

provide a function to control Ignition Gazebo (create model, etc) in ROS, which is based on service's transfer , just like ros_ign_gazebo/src/create

In that case, maybe it makes more sense to add the missing functionality to the existing create node?

[gezp]

Oh, thank you for the clarification, I thought that your solution would be generic.

ign_gazebo_manager is a bundle of specific services for Ignition Gazebo. it's a service's bridge, but also specific for Ignition Gazebo, I am not sure to add it in ros_ign_bridge or ros_ign_gazebo.

Perhaps, the generic code from ign_gazebo_manager can be wrapped and added to ros_ign_bridge .

In that case, maybe it makes more sense to add the missing functionality to the existing create node?

create node is a executable, which is useful to create model in ROS launch file.
ign_gazebo_manager is a service's bridge, which is useful to create model at ROS task's runtime.
i think they are both useful in different way.

[gezp]

I create a c++ class template for general service bridge (only ROS Client -> Ignition Service), and any advice is welcome.

• https://github.com/gezp/ros_ign_gazebo_manager/blob/main/src/service_bridge.hpp
• service bridge example: https://github.com/gezp/ros_ign_gazebo_manager/blob/main/src/ign_gazebo_manager.cpp

In addition, i have some questions about implementation of service bridge .

do we need bidirectional service bridge like topic?

In my opinion, we needn't. I think only unidirectional service bridge（ ROS Client -> Ignition Service）is useful.

do we need factory interfaces to create service bridge from string of service type, so that we can create service bridge in launch file ?

In my opinion, we needn't. There are various of services (ROS .srv) which are made up of different messages (ROS .msg), so it's more complex than topic bridge.

[ivanpauno]

Hi @gezp, did you make any further progress related to this issue?

I might need to work in this ticket in a near future.

[gezp]

no, i have no plan, you are free to work in this ticket @ivanpauno .

[jacobperron]

Is this ticket resolved with #211?

[ivanpauno]

I think so, we can open follow-up tickets if something is missing.