ROS2 Relative spawning

[pijaro]

What does this PR do?

Enables spawning entities in an arbitrary coordinate system.

Similar to spawning in WGS coordinate system, enabling the option and setting "relative" in ROS 2 service "reference_frame" spawns entity relatively to the selected coordinate system.

How was this PR tested?

1. Spawning with feature off
2. Spawning with feature on/off and with/without reference frame set
3. Checked different positions of reference frame

[jhanca-robotecai]

What is the difference between the reference_frame (using AZ::Entity) and the ROS2SpawnPointComponent introduced earlier? Is there a need to use both? This feature should be implemented following a discussion (maybe RFC?), as there are many problems around the spawner topic.

[pijaro]

reference_frame is used when we want to spawn an object using (x, y, z) coordinates. The default coordinate system is at O3DE root - (0,0,0) and no rotation. The reference_frame changes it to any other system - useful when we want to spawn an object relatively to another object. It is common to use georeference component that is practically our new "origin" of the level, and we want to use it instead of global O3DE (0,0,0).

Named spawn points (ROS2SpawnPointComponent) positions are implicitly defined (a location in a level, we don't truly care about the coordinates) and are always in O3DE root (0, 0, 0). Relative spawning has no use in that case.

To sum up, these two frames are solving different issues and serves different purposes.

[jhanca-robotecai]

Why not adding an option to spawn an object using xyz coordinates with a named spawn point used as a reference frame? I still don't get why do we need another tooling for that. The change looks like a quickfix for a particular problem within a particular project.

gazebo_msg package is deprecated and we will be removing it in the next full O3DE release, hence most of the spawner's code will be reimplemented. We could start the work already by preparing an RFC and start listing all features that should be included in the spawner.

[adamdbrw]

Could you make it compliant with incoming simulation_interfaces?

[pijaro]

Why not adding an option to spawn an object using xyz coordinates with a named spawn point used as a reference frame?

That is an alternative way of doing it.

However, I would argue if it is more semantically correct. In my opinion, it would be a better idea to guide the spawner where its reference frame really is (as this is a level-only information, like the position of geo frame in a level), rather than passing that in the message. Your suggestion looks like adding an "offset" to spawning point, rather than changing the reference frame.

This PR adds a feature that is very useful in any project that uses WGS geo reference origin.