Bridge parameters

[chapulina]

Desired behavior

ROS parameters provide a convenient way to manipulate properties of a node at runtime. It would be convenient for users to be able to alter simulation properties through ROS parameters.

Alternatives considered

All configuration could be exposed through topics, which can be bridged using ros_ign_bridge.

Implementation suggestion

It would be interesting to provide a generic "parameter bridge" that provides a parameter interface on the ROS side, and an Ignition Transport service interface on the simulation side.

Additional context

ROS 2 parameters themselves are built using services under the hood. So I think we can translate the same idea to ros_ign_bridge.

[ivanpauno]

It would be convenient for users to be able to alter simulation properties through ROS parameters.

What is the current way to alter simulation properties in ignition/ignition plugins?
I'm not quite sure of what ros parameters are going to be bridged to (does ignition have something equivalent to parameters (?)).

[ivanpauno]

examples:

The gazebo_ros_pkgs wheel slip plugin is using ROS parameteres to dynamically reconfigure slip parameters, or the camera plugin is using a ros parameter to dynamically reconfigure the camera update rate.

What's the recommended way in ignition to "expose" reconfigurable properties through ignition transport?
I was checking the wheel slip subsystem, and it seems that all slip parameters are currenly being loaded from the sdf file and are not exposed in any way through ignition transport.

If there's no current recommended way to do that, I can try to propose one (and a mapping to ROS parameters).

[chapulina]

does ignition have something equivalent to parameters (?)

Nope

What is the current way to alter simulation properties in ignition/ignition plugins?

We currently have support for doing it through transport topics / services, or directly on C++ through components.

I'd say that among all of these, the easiest one to bridge would probably be ign-transport services that are provided by the UserCommands system.

What's the recommended way in ignition to "expose" reconfigurable properties through ignition transport?

The approach we've been taking to expose configurations to the GUI, for example, is to add a service to UserCommands, which sets a component with the Cmd suffix. See an example in

• Edit material ambient/specular/diffuse/emissive in component inspector gz-sim#1123

[ivanpauno]

The approach we've been taking to expose configurations to the GUI, for example, is to add a service to UserCommands, which sets a component with the Cmd suffix. See an example in

That makes sense.
The only big difference I see with ROS parameters is that there doesn't seem to be a way to intronspect the current user command setting from ignition transport.

e.g. gazebosim/gz-sim#1123 added a /world/default/visual_config service, which allows to set the visual config based on the request defined by a visual msg.
But there doesn't seem to be a way to intronspect the current visual config.

This is probably enough though, e.g. for the wheel slip plugin having the ability to reconfigure the slip parameters is the most important thing. Instronspection can be solved by first calling the service and remembering the last parameters set (assuming that there's no other externsal source modifying the parameters).

---

Regarding how to bridge ignition UserCommands to ROS, they could be mapped to either parameters or to services.

Mapping them to parameters is going to be a bit cumbersome though.
e.g. The light command has 14 attributes (not counting, id, parent id, name, and the header), that should be mapped to 14 parameters.
The light name could be used to namespace the ROS parameters (this is sort of what it's done in gazebo_ros_pkgs with ROS 1 dynamic reconfigure parameters and ROS 2 parameters, e.g. the camera image rate is namespaced with the camera name).
For each SetParameters request a ros node receives, we should filter all parameters that correspond to that user command and send a request to the ignition service.
The parameters that were not provided in the set parameter requests will be set to the last value the parameter had in the ignition service request.
In the same fashion, GetParameters request can be answered with the parameter values bookkeeped by the node.
When the node starts, a request should be send to the corresponding ignition service using the default parameter values (to ensure the internal bookkeeping is valid).

The mapping to ROS service is more natural.
The only disadvantage of that approach is that it's not going to be a bit different to what gazebo_ros_pkgs provided.

[chapulina]

But there doesn't seem to be a way to intronspect the current visual config.

All the simulation state is held in the EntityComponentManager and is available to external programs through the state topic / service. There's a standalone example here showing how any external application can get the full simulation state through transport.

So... There isn't a granular way of getting just the visual config, but there's a way to get it.

The only disadvantage of that approach is that it's not going to be a bit different to what gazebo_ros_pkgs provided.

I wouldn't worry too much about that, the whole philosophy of ros_ign is very different from gazebo_ros_pkgs. I think we should focus on covering the necessary use cases, making it usable and easily extensible.

[ivanpauno]

I wouldn't worry too much about that, the whole philosophy of ros_ign is very different from gazebo_ros_pkgs. I think we should focus on covering the necessary use cases, making it usable and easily extensible.

In that case, I think that the most natural way to port things that used dynamic reconfigure parameters in gazebo_ros_pkgs is to expose a similar ignition service in the UserCommands system and add support to bridging services here.

e.g. the wheel slip plugin was used to make the slip parameters available through dynamic reconfigure, and using rqt_reconfigure you could easily modify them.
To cover the same necessity, an user command to reconfigure wheel slip parameters could be added (currently the wheel slip system seems to only be configurable from the sdf description).
Through a ros_ign service bridge the wheel slip parameters could be made reconfigurable from ROS.
To have an UI, equivalent at what rqt_reconfigure provided, I think the best thing to do is to add that to ignition itself (similarly to what was done in gazebosim/gz-sim#1123).
rqt_reconfigure is available in ROS 2, but it works using parameters.

[ivanpauno]

All the simulation state is held in the EntityComponentManager and is available to external programs through the state topic / service. There's a standalone example here showing how any external application can get the full simulation state through transport.

A bit unrelated to the discussion here, but I think it would be nice to have a way to easily get a particular entity.
Maybe a wrapper on top of the existing topic/service, or a "get entity" service.
Maybe all user commands, could have a get_* service.
e.g. /world/default/visual_config (req type: Visual, res type: bool) and /world/default/get_visual_config (req type: Empty, res type: Visual) for the VisualCmd .

[scpeters]

A good example would be to bridge the wheel slip parameters after completing gazebosim/gz-sim#1845