[ros2] Port spawn/delete methods

[j-rivero]

Part of the re-factor works for issue #779

This PR will generate the gazebo_ros_factory plugin that should take care of the spawn and delete methods. I did not touch most the code that manages the XML although there is plenty of space there to improve.

I've fixed the problems with uncrustify and other cpp checks but the PR lacks of tests (sorry about that) and I did not integrate the plugin in the standard calls so it can be consider a WIP until we do it.

[chapulina]

Thanks for the PR @j-rivero ! I'll pick it up from here since you're OOO. My current plan is to:

• Rename spawn_model to spawn_entity
• Migrate the deletion services and merge into a single one called delete_entity
• Use gazebo_ros/conversion functions as much as possible
• Add a couple of tests for spawn and delete
• Add a migration guide

[chapulina]

Some convenient commands to test spawning:

SDF model

Static model with a visual

ros2 service call /spawn_entity 'gazebo_msgs/SpawnEntity' '{name: "sdf_ball", xml: "<?xml version=\"1.0\" ?><sdf version=\"1.5\"><model name=\"always_ignored\"><static>true</static><link name=\"link\"><visual name=\"visual\"><geometry><sphere><radius>1.0</radius></sphere></geometry></visual></link></model></sdf>"}'

With a plugin, without <ros>

ros2 service call /spawn_entity 'gazebo_msgs/SpawnEntity' '{name: "sdf_ball2", robot_namespace: "custom_ns", xml: "<?xml version=\"1.0\" ?><sdf version=\"1.5\"><model name=\"always_ignored\"><link name=\"link\"><visual name=\"visual\"><geometry><sphere><radius>1.0</radius></sphere></geometry></visual><collision name=\"collision\"><geometry><sphere><radius>1.0</radius></sphere></geometry></collision></link><plugin name=\"force\" filename=\"libgazebo_ros_force.so\"><link_name>link</link_name><ros/></plugin></model></sdf>"}'

With a plugin, with <ros> and <namespace>

ros2 service call /spawn_entity 'gazebo_msgs/SpawnEntity' '{name: "sdf_ball3", robot_namespace: "custom_ns", xml: "<?xml version=\"1.0\" ?><sdf version=\"1.5\"><model name=\"always_ignored\"><link name=\"link\"><visual name=\"visual\"><geometry><sphere><radius>1.0</radius></sphere></geometry></visual><collision name=\"collision\"><geometry><sphere><radius>1.0</radius></sphere></geometry></collision></link><plugin name=\"force\" filename=\"libgazebo_ros_force.so\"><link_name>link</link_name><ros><namespace>banana</namespace></ros></plugin></model></sdf>"}'

SDF light

ros2 service call /spawn_entity 'gazebo_msgs/SpawnEntity' '{name: "bulb", xml: "<?xml version=\"1.0\" ?><sdf version=\"1.5\"><light name=\"always_ignored\" type=\"directional\"></light></sdf>"}'

URDF robot

ros2 service call /spawn_entity 'gazebo_msgs/SpawnEntity' '{name: "urdf_ball", xml: "<?xml version=\"1.0\" ?><robot name=\"always_ignored\"><link name=\"link\"><visual><geometry><sphere radius=\"1.0\"/></geometry></visual><inertial><mass value=\"1\"/><inertia ixx=\"1\" ixy=\"0.0\" ixz=\"0.0\" iyy=\"1\" iyz=\"0.0\" izz=\"1\"/></inertial></link></robot>"}'

[chapulina]

Migration guide: ROS 2 Migration: Spawn and delete

[dhood]

curious if in gazebo a model and light could both exist with the same name? (trying to think of side-effects of merging the services)

[chapulina]

curious if in gazebo a model and light could both exist with the same name? (trying to think of side-effects of merging the services)

That's a valid concern. Gazebo doesn't enforce name uniqueness among different entity types, which means there can be different entities with the same scoped name, which causes several issues like this one.

But that isn't something which can be fixed from gazebo_ros_pkgs:

• The spawn methods have always handled both lights and models, the services were actually previously split between SDF and URDF, not according to entity type. So renaming SpawnModel to SpawnEntity keeps the old behaviour while having a more appropriate name.

• As for deletion, even though gazebo_ros_pkgs provided separate DeleteLight and DeleteModel services, both of them called the same Gazebo request entity_delete. So really, they've always been the same service and you could delete lights using the model service and vice-versa.

[chapulina]

A little demo:

[nuclearsandwich]

Reviewed the migration guide entry as well and it looks good too!