Hello.
I would like feedback on how to make these tools better.
Thank you in advance.
Reminded me of this (start of a) discussion:
opened 12:49PM - 05 Nov 24 UTC
## Problem
The number of simulator choices for ROS increased over time, and t… hese simulators offer different advantages and trade-offs. For certain applications **Gazebo** is a match, for others, **Open 3D Engine (O3DE)** does the job the best, and for others yet, Isaac Sim might be a fit. There are many more yet.
Open 3D Engine robotic simulation (the ROS 2 Gem) depends on _gazebo_msgs_ package, which was deprecated with the Jazzy release, but also, as an exception, released to make life easier for O3DE users. The _gazebo_msgs_ package interfaces are quite generic and thus were reused in O3DE. However, **one simulator interface user experience should not depend on a release cycle of another simulator**, but rather be tied to a certain standard.
There is currently **no standard for simulation interfaces**. Simulation interfaces include spawning and de-spawning of robots and other entities, moving them around, pausing and resetting the scene, and so on. They are also **highly important for automation of simulation-based testing**. These interfaces are mostly services as they offer valuable response interaction which is needed for almost all the interface features.
## Proposed solution
A new **_simulation_interfaces_** package which reuses much of _gazebo_msgs_ but also introduces new interfaces and changes some fields to fully support current Gazebo and O3DE community needs. The priority for the first release should be minimizing impact (including semantic differences) for the users, and capturing new requirements in new services rather than re-imagining the entire package.
## Current state of O3DE interfaces in use
I come with the O3DE perspective and invite others to supply other perspectives. Note that current use for some of services and their fields is not adhering to their intended semantics, and includes extension Gems beyond the core ROS 2 Gem.
Services for simulation entities spawning and control (all are [_gazebo_msgs/srv/_](https://github.com/ros-simulation/gazebo_ros_pkgs/tree/ros2/gazebo_msgs/srv) services):
| Service name | Service Type | Description |
|----|----|----|
| get_available_spawnables | GetWorldProperties | Return a list of spawnable names (e.g. _turtlebot4_). |
| get_spawn_points | GetWorldProperties | List named (pre-set) spawn points to use, e.g., “kitchen.” |
| get_spawn_point_info | GetModelState | Get a pre-set spawn point by name, returning its pose and description. |
| spawn_entity | SpawnEntity | Spawning robots and other entities by prefab name. |
| delete_entity | DeleteEntity | Despawn by unique name (e.g. _turtlebot4_1_). |
| get_scene_objects | GetModelList | Acquire dynamic objects which can be controlled (other than the robot). |
| get_object_state | GetEntityState | Acquire information about a specific simulation object. |
| set_object_state | SetEntityState | Instantly change the pose or Twist of an object. |
Services for simulation scenes and control, especially important for automation with scenario testing (multiple runs of simulation on different scenes). Note that some services are not used semantically as intended, and some services are custom here indicating there is no great fit in current _gazebo_msgs_ interface set:
| Service name | Service Type | Description |
|----|----|----|
| load_level | custom | Load a named level, if another was loaded before, it is unloaded first. |
| get_current_level | custom | Get the current level of the simulation. Fails if no level is running. |
| get_available_levels | GetModelList | Get the available levels of the simulation. |
| reset_current_level | std_msgs/srv/Trigger | Reset the current level of the simulation. |
| unload_current_level | std_msgs/srv/Trigger | Unload the current level of the simulation. |
| set_simulation_paused | std_srvs/srv/SetBool | Pausing and un-pausing. |
## The benefits
Standardization would improve user experience when using their validation, testing and ML pipelines with several simulators, or when switching between one simulator and the other as they needs come to better match another platform. It would also make it easier to benchmark simulators.
## Discussion
- What would be the minimal _simulation_interfaces_ package that would have the lowest adaptation cost for Gazebo?
- Going from there, how can we best cover O3DE utility with reasonable addition of optional fields and services to such package?
- As a community member, could you provide what is different in perspective of your simulator?
Please take a look, @azeey.
2 Likes
Thank you for your comment.