[ROS2] Multiplayer support

[lgleim]

Summary

Add support for multiplayer (client/server) simulation to the ROS2 Gem, based on a (Gazebo-inspired) "fat-client" architecture, using an O3DE server for state synchronization among clients.

What is the relevance of this feature?

There are an increasing number of use cases for simulating fleets of robots.

One area of application is in the context of warehouse simulation (cf. the Ros2FleetRobotTemplate) where many AMRs need to be simulated in the same environment.

While O3DE is already capable of simulating the physics of many robots (100+) on a single machine, there are clear limits to single-node scalability. This work should raise that ceiling and explore the scalability of an architecture with centralized state synchronization.

Feature design description

To evaluate the feasibility and scalability properties of multi-robot simulation in O3DE using a traditional Client-Server architecture, support for the O3DE Multiplayer Gem should be added to the ROS2 Gem.
Developers will then be able to simulate different robots on different machines, while the simulation state will be synchronized through a central game server. This approach is analogous to traditional multiplayer gaming.

Loosely inspired by the architecture of Gazebo Ignition, which employs a central "primary" for synchronizing the state of the simulation, we plan to make use of the O3DE Multiplayer Gem, creating

• A single, central simulation Server: Responsible for state synchronization (transforms, physics-state) and not simulating any ROS2-specific components (as far as possible)
• One Client per robot: All "heavy" components (e.g. rendering of camera sensors / LIDARs, control, ROS communication) are handled exclusively by one client, which is realized through the "Autonomous" role

Technical design description

• Add a Utility function that allows ROS2 Components to determine if they are running in a multiplayer environment & if yes, if in autonomous / authorotative role to adapt their behavior accordingly
• Adapt CMakeLists.txt to Multiplayer build configuration
• Adapt ROS2 Sensor Components such that they are only activated when in "Autonomous" role
• Adapt ROS2 Controller Components such that they are only activated when in "Authority" role
• Adapt ROS2SystemComponent such that each client has a distinct ROS2 node name
• Adapt ROS2SpawnerComponent such that the assigned namespaces do not clash, e.g. using random namespace suffixes
• Extend ROS2SpawnerComponent based on Simple Network Player Spawner Component to assign the autonomous role to robots in multiplayer mode
• Fix PhysX Joints not created in Multiplayer Mode o3de#16020
• Adapt SimulationClock.cpp to publish a namespaced simulation clock (i.e. one simulation clock per node simulating robots)

What are the advantages of the feature?

• Increased scalability of Robotics Simulation with O3DE
• An additional example of developing "multiplayer" applications with O3DE

What are the disadvantages of the feature?

• Increased complexity of the ROS2 Gem codebase
• Likely additional Editor Components for the users to configure

How will this be implemented or integrated into the O3DE environment?

• This change would introduce the Multiplayer Gem as an additional build dependency to the ROS2 Gem
• Users should not Explain how a developer will integrate this into the codebase of O3DE and provide any specific library or technical stack requirements.

Are there any alternatives to this feature?

• Reducing simulation complexity to improve single-node performance
• An e.g. spatially-partitioned multiserver architecture, in which the ROS2 components should only be executed when in "Authority" role. However, since the multiserver GEM is AWS-proprietary, this is not a viable option for the ROS2 Gem currently. Mostly, the other planned modification apply equally.
• Instead of creating "Autonomous-authoritative" versions of the NetworkTransform & NetworkRigidBody components, the ROS2 controllers could be adapted to be NetworkControllers. This requires more changes to the ROS2 Gem Controller Architecture though.

How will users learn this feature?

• A multiplayer version of the ROS2FleetTemplate should be created
• A tutorial for setting up multiplayer support for a ROS2 O3DE Simulation should be provided
• Documentation should be augmented for any behavioral changes / additional setup & configuration steps

[adamdbrw]

@lgleim was there any further work done on this? Do you have a preferred course of action?